I'm doing my best to not be an "insane weirdo" by focusing on the correctness of code, and to ignore the extra blank lines and spaces, lack of a space in between the "//" and the first word of the comment, and inconsistent camel casing in the work of some of my colleagues.
If you can, commit wholely to a parsing formatter and plug it into your CI pipeline. I've come to realise over the years that its not style I care about per-se, but consistency. With a parsing formatter and an opinionated linter, you're pretty much covered automatically across all development and developers.
Yep -- where I work, every language we use in any big way has a high-quality automated formatter, and we require all code to be formatted with these tools. It's been a dramatic improvement in code readability in general across the company. We have a few engineers who would consistently beat the formatter by a very small margin if they were formatting their code by hand, but they are the exception -- 95% of the code submitted across the company is improved by these tools.
> My hope is that people like to see their name when they "git blame"
Sadly, my impression is that a lot of people don't want to see their own names on git blame, because they fundamentally operate on "you break it, you buy it" mode. As long as their name isn't associated with a particular piece of code, it's not their fault that it's broken. (It doesn't matter that the code is fundamentally broken and has been broken since inception five years ago - not my fault!) Here, let me just add a quick wrapper layer on top of it so that my module can work around the bug, while at the same time making my module depend on the broken behavior...
I think some people just have better or worse tolerances to these things than others.
If formatting in code is as I am used to it, I can skim it very quickly. If it is not, I have to focus much more, and that adds up over the course of a day.
My brain can just recognize what's happening in a small block of code if it has a particular shape and colors. I don't know how to explain it better than that.
This is one reason I REALLY want to see editors save files as tokens rather than plain text, and see compilers ingest code as pre-parsed tokens rather than plain text. (Or have editors save the tokenized file alongside a plain text file for the compiler.)
If that ever happens, I will be able to view the code exactly as I like it, and so will everyone else, even when we each want to view it differently.
Compilers and diffing tools will need to report a token number rather than a line number for errors and differences, and I don't see that as a big problem at all.
On the other side, at my current place of work, there's one person that throws a fit every time someone is not following the linting rules, the CI/CD rejects anything, mostly trailing trailing spaces. What drives me nuts is not the fact that he's obsessed with them, but that he actually put no thought whatsoever into what rules to apply, he just put the first one he found on the internet, and is regiouly following them and forcing them on the rest of us.
The bigger the codebase and the more people in an org the more important coding standards are. But enforcing them should be 100% automated with a linter failing PRs that introduce incorrectly styled code (or precommit hook). That makes it so it doesn't waste code review time.
Just use a linting tool? Using a linter allows me to care a lot about formatting (which I do) while not consuming a ton of my team’s time enforcing it.
This is a tiny fraction of the time that it takes to comment on PRs/CLs in perpetuity. The alternative is just to literally not care about formatting which if you are able to do more power to you, but I could not imagine working on such a team. To me it’s somewhat akin to saying that all that matters in writing is the ideas, not the formatting of a document.
Organize one meeting, tell everyone you don't care which one but they have to decide on one by the end of the meeting. Otherwise you're deciding one for them (phrase it as "I have a PR ready to go adding this one"). Assuming you have the sufficient authority (managerial, technical, or buy-in from your manager) for such an ultimatum, of course.
Yes, we use golangci-lint for our few Go projects, which works well. However, most of our projects are in Java, and the mistake of our team was to never have our Checkstyle break the build. So, the result is many Java repos with a variety of coding styles.
If your preferred codestyle can't be expressed in a standard formatting tool, change your code style and run the autoformatter once. Have a bot make the commit if you care about your diff histories.
I find that the people that over stress code style (developer version of the grammar Nazi) end up wasting their social capital and overall energy.
They lose capital going back and forth in these squabbles and lose their ability to look for much bigger danger signs such as over abstractions, under abstractions, and convoluted code.
