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@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 :)