Recently I have been reading other people's coding style.
I have read Rob Pike's, suckless', some 9front developers', and NetBSD and OpenBSD coding styles.
Those documents inspired me to write down all the subjective practices I have in my mind into objective conventions. And thus I wrote my coding style.

What do you think of those coding styles?
Do they enforce good practice or are they too normative to be feasible?
Do you have a coding style you follow in your projects? If yes, why not writing it down?

I've always liked OpenBSD C coding style and so I follow it for my personal projects.
However, in my opinion, any style is good as long as it's consistently used across all the project, for me it doesn't make much of a practical different only than a vision aspect and expectations.

When I'm writing C, it's a combination of kernel style (which Emacs is configured to) in addition to putting return values on separate lines.

I don't think there are distinct styles in Lisp, but I put long arguments on separate lines, with the first one sharing the line of the function name, like so:


It makes it nice and readable, and fits well with the semantic understanding of Lisp as a tree.

I don't even think I have a coding style, especially as most of that depends on the underlying language and - in some cases - the compiler's tolerance.

I confess, I've always been sloppy when it comes to coding style. But I recently added an autocommand to my vimrc to reformat my code before saving it, using astyle(1):


In turn my astylerc enforces rules loosely based on the NetBSD style guidelines, but is still evolving:


Explanation of these astyle settings can be found here.

Names: the shorter the better, but I agree with the consensus that wider scope calls for a longer name. I occasionally lapse into CamelCase or the use of underscores to separate words in a name, but I don't really like either style. When I worked at Microsoft, Hungarian notation was de rigeur, but I absolutely loathe it and don't see how it can achieve its goals without compiler support.

I like the NetBSD rules for ordering #includes. Again, this is something where I've been sloppy in the past.

I still have old-school tendencies when it comes to declaring local variables, putting them at the beginning of the function and sorting by size. But I don't usually bother to sort variables of the same type alphabetically (maybe I should). I understand the value of declaring variables with even narrower scope, but I'm working on breaking old habits.

One thing that interested me in phillbush's styleguide was alphabetically sorting the cases in a switch statement. I've tended to arrange them according to logical sub-groups or in order of likeliness instead. But now I wonder what difference (if any) it makes in the generated code. Something to explore on the next rainy day!

(25-05-2021, 02:49 PM)ckester Wrote: In turn my astylerc enforces rules loosely based on the NetBSD style guidelines, but is still evolving:

That's the first time I heard about astyle, thanks for pointing it out. I know about indent(1), that does the same job. However, astyle seems to be more full-featured than BSD indent(1). There's also GNU indent(1), but I do not trust it, as it has the awful GNU coding style as default.

NetBSD also has a indentrc in its source tree.
OpenBSD does not have a standard indentrc, but I will steal the one from this reddit post.

I never used indent(1) nor astyle(1). I will try the first (which is already available in all BSDs), mapping it to gq in vim (a keybinding I use to format prose, but that has no use in code). If I find that it does not fit my style I'll try astyle then.

(25-05-2021, 02:49 PM)ckester Wrote: I occasionally lapse into CamelCase

That's actually PascalCase, camelCase has the first letter in lowercase.

(25-05-2021, 01:34 PM)opfez Wrote: When I'm writing C, it's a combination of kernel style (which Emacs is configured to) in addition to putting return values on separate lines.

Emacs defaults to GNU coding style! Run away from it!

(25-05-2021, 01:34 PM)opfez Wrote: I don't think there are distinct styles in Lisp, but I put long arguments on separate lines, with the first one sharing the line of the function name, like so:

Code:

(cond ((some-long-predicate-foo a) 3)
      ((another-long-bar b) 4)
      (else 6))

It makes it nice and readable, and fits well with the semantic understanding of Lisp as a tree.

I'm reading SICP. It's the first time I touch LISP, so I'm just using its style for scheme (the same way as I copied K&R style the first time I touched C, while reading K&R).

I'd say I agree with pretty much everything said so far. Here are a few of my own for interpreted languages, which I probably should write down somewhere:

• Don't call other turing complete languages when your shell can already do basic string manipulation.
  
• Use #!/usr/bin/env python, not #!/usr/bin/python.
  
• Don't include huge walls of text as comments, write proper documentation instead.
  
• Use the heredoc format, not dozens of echo or printf statements.
  

Talking of vim, it's definitely worth mentioning vim modeline magic. Many projects use this.
Maybe others know more techniques to enforce style with linters like astyle (which was mentioned) or indentrc. Some languages have built-in linters too.

Here’s the GNU Emacs equivalent:
https://www.gnu.org/software/emacs/manua...ables.html

(25-05-2021, 09:58 PM)phillbush Wrote: Emacs defaults to GNU coding style! Run away from it!

Oh I miswrote, I meant I've configured Emacs to use kernel style. I agree that the GNU style is hideous.