C Style #13

New Issue

trinity · 2023-12-26T15:58:12Z

trinity commented

2023-12-26 15:58:12 +00:00

The current style in CONTRIBUTING is 80col tabstop=2. I like 80 columns (my framebuffer on my cutepad isn't much wider) but 2-char tabs cause some issues for me:

Most projects use a tabstop of 4 or 8, so I have to have a special configuration for my text editor for Bonsai projects.
Rustfmt's default tabstop is 4. Gofmt's default tabstop is 8. I know rustfmt can be configured but I'm not so sure about gofmt. It would be nice to be able to take advantage of these tools.
I wrote many of the utilities included in tabstop=8 so the formatting looks pretty bad, particularly goto labels which are meant to be short enough to fit in a tabstop so they don't disturb the amount of tabs with which lines are indented and stick out as one of the few unindented elements. Some comments also suffer from this ugliness as a result of the conversion but these can be cleaned up, gotos can't (even u: instead of usage: would occupy an entire tabstop). Gotos are necessary for flow control, used to break out of multiple layers of loops. The alternative without gotos would be clunky. In particular see src/str.c:56. usage: gotos can be relegated to functions that end in exit(3) but I would prefer to return from main.
I find it hard to read 2-char tabs. I understand this is subjective.

I think in C enforcing 4-char tabs, and tabs as '\t', would be nicer, and for Go and Rust source files using gofmt and rustfmt respectively before committing them.

My favorite option for C would be 8-char tabs and '\t' as this is the default in nearly all terminal emulators and it would be a nice win for the sufferers of ed(1). Acme and Sam from Plan 9 also have this as an unconfigurable default. However I don't think this would be a popular choice.

The current style in CONTRIBUTING is 80col tabstop=2. I like 80 columns (my framebuffer on my cutepad isn't much wider) but 2-char tabs cause some issues for me: - Most projects use a tabstop of 4 or 8, so I have to have a special configuration for my text editor for Bonsai projects. - [Rustfmt's default tabstop is 4.](https://github.com/rust-lang/rustfmt/blob/master/Configurations.md#tab_spaces) [Gofmt's default tabstop is 8.](https://cs.opensource.google/go/go/+/master:src/cmd/gofmt/gofmt.go;l=46) I know rustfmt can be configured but I'm not so sure about gofmt. It would be nice to be able to take advantage of these tools. - I wrote many of the utilities included in tabstop=8 so the formatting looks pretty bad, particularly goto labels which are meant to be short enough to fit in a tabstop so they don't disturb the amount of tabs with which lines are indented and stick out as one of the few unindented elements. Some comments also suffer from this ugliness as a result of the conversion but these can be cleaned up, gotos can't (even `u:` instead of `usage:` would occupy an entire tabstop). Gotos are necessary for flow control, used to break out of multiple layers of loops. The alternative without gotos would be clunky. In particular see [src/str.c:56](https://git.tebibyte.media/bonsai/coreutils/src/branch/main/src/str.c#L56). `usage:` gotos can be relegated to functions that end in `exit(3)` but I would prefer to return from main. - I find it hard to read 2-char tabs. I understand this is subjective. I think in C enforcing 4-char tabs, and tabs as `'\t'`, would be nicer, and for Go and Rust source files using gofmt and rustfmt respectively before committing them. My favorite option for C would be 8-char tabs and `'\t'` as this is the default in nearly all terminal emulators and it would be a nice win for the sufferers of ed(1). Acme and Sam from Plan 9 also have this as an unconfigurable default. However I don't think this would be a popular choice.

emma commented

2023-12-26 18:03:20 +00:00

that 2-tabstop thing is inherited from my other projects :P i’ll change it to 4 later and add a .editorconfig

❤️ 1

emma added the

enhancement

label 2023-12-26 18:22:06 +00:00

emma self-assigned this 2023-12-26 18:24:38 +00:00

emma closed this issue

2023-12-29 06:22:05 +00:00

trinity commented

2023-12-29 20:09:07 +00:00