C Style #13

Closed
opened 2023-12-26 08:58:12 -07:00 by trinity · 2 comments
Owner

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.
Owner

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

that 2-tabstop thing is inherited from my other projects :P i’ll change it to 4 later and add a .editorconfig
emma added the
enhancement
label 2023-12-26 11:22:06 -07:00
emma self-assigned this 2023-12-26 11:24:38 -07:00
emma closed this issue 2023-12-28 23:22:05 -07:00
Author
Owner

Why was this closed?

Oh, a .editorconfig was added to clarify the style. Thank you!

Why was this closed? Oh, a .editorconfig was added to clarify the style. Thank you!
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: bonsai/harakit#13
No description provided.