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