5 ms·

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 betwee

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.

chenmike 6y ago
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.
- dimtempo84 6y ago
  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.
  - dboreham 6y ago
    This is just how life turns out ime. Focus on more important things.
- dboreham 6y ago
  Then you get to have many meetings about which litter and lint rules to use.
  - chenmike 6y ago
    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.
  - jogjayr 6y ago
    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.
  - disgruntledphd2 6y ago
    This is why I like black, for Python. It doesn't have any configurable settings, which means way less arguments.
dboreham 6y ago
I wouldn't worry. In my (long) experience there are many of you.
alain_gilbert 6y ago
I used to be an "insane weirdo", but at some point I gave up. Now, I just focus on code correctness, merge and fix the code style myself, avoiding a lot of useless back and forth. My hope is that people like to see their name when they "git blame" (what's the PC version of "blame" again?) So they will over time learn to follow the code style in order to keep their name there.
- david_allison 6y ago
  > what's the PC version of "blame" again? JetBrains uses "annotate"
- evan_ 6y ago
  Credit
  - leetrout 6y ago
    I like that a lot.
- dozzman 6y ago
  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.
  - nilkn 6y ago
    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.
- yongjik 6y ago
hctaw 6y ago
Use an autoformatter and be done with it. 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.
runawaybottle 6y ago
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.
harrisonjackson 6y ago
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.
gryn 6y ago
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.
naikrovek 6y ago
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.

chenmike 6y ago

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.

dimtempo84 6y ago
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.
- dboreham 6y ago
  This is just how life turns out ime. Focus on more important things.
dboreham 6y ago
Then you get to have many meetings about which litter and lint rules to use.
- chenmike 6y ago
  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.
- jogjayr 6y ago
  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.
- disgruntledphd2 6y ago
  This is why I like black, for Python. It doesn't have any configurable settings, which means way less arguments.

dboreham 6y ago

I wouldn't worry. In my (long) experience there are many of you.

alain_gilbert 6y ago

I used to be an "insane weirdo", but at some point I gave up. Now, I just focus on code correctness, merge and fix the code style myself, avoiding a lot of useless back and forth. My hope is that people like to see their name when they "git blame" (what's the PC version of "blame" again?) So they will over time learn to follow the code style in order to keep their name there.

david_allison 6y ago
> what's the PC version of "blame" again? JetBrains uses "annotate"
evan_ 6y ago
Credit
- leetrout 6y ago
  I like that a lot.
dozzman 6y ago
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.
- nilkn 6y ago
  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.
yongjik 6y ago

hctaw 6y ago

Use an autoformatter and be done with it. 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.

runawaybottle 6y ago

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.

harrisonjackson 6y ago

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.

gryn 6y ago

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.

naikrovek 6y ago

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.