4 Aug
2023
4 Aug
'23
7:58 a.m.
What we've done on my current project is pretty much equivalent to the
route Go chose.
Go has go fmt; doesn't matter what you personally believe, just run that
pre-commit, and you get a consistent style. For Python we use black. Same
idea. It's not what everyone would have chosen--in fact, precisely what it
does is not what *anyone* on the project, probably, would have chosen--but
the fact is, it does something sane and pretty readable, and then there's
no fighting over style.
Adam
On Thu, Aug 3, 2023 at 6:28 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
That said, as
a person who thinks of himself as a professional, when I go
in to someone else's code, I adopt their style. It's really rude to not
do so. I've written code in GNU C style.
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
I've adopted a variation on this in that I try and write additions to
existing code stylistically similar to what is there, anything presenting
glue logic to some sort of external vendor library in a way resembling
their style, and then anything else is mine.
That middle one I've found particularly helpful even for myself over the
years as there are plenty of places in the dayjob codebases I can drop in
and tell almost immediately "Oh this is a wrapper over so and so based on
the variable names" or "Yeah this is an interface to library <xyz> based
on
the way the operations are named."
Generally the only thing I have a hard time sticking to is casing, I'm a
fervent snake caser in my assembly and C code, but then fervent pascal
caser in my JavaScript and C#. Then again, that may also tie into my
middle practice in that those are the common cases seen in model examples
of those languages. One of the weirder side effects of that stylistic
practice is the rare occasion where I blindly copy something between
languages with relatively similar syntax (C to C# or JavaScript for
instance) I can tell going back later because there's a hunk of code with
snake case smack in the middle of a bunch of pascal case. I usually go and
clean that up though because otherwise the codebase starts to look like a
copypaste job from StackOverflow after a while, that stuff drives me up the
wall.
- Matt G.
P.S. For TUHS subject appropriateness, I have TUHS to thank for my C style
practices. I learned from KnR 2nd Edition back when I was a kid, but
diverged a bit from the typical KnR way of things for a while, when I
caught wind of TUHS and started pouring over all the code, unbeknownst to
my own consciousness I started absorbing stylistic patterns from UNIX
sources. I'm thankful to Warren and all the others who have facilitated
this community, I think TUHS should be in any programmer's bookmark list :)