Hacker News Reader

Comment by chipdart | Hacker News Reader

> over trivial style nonsense

What's your definition of "trivial style nonsense"? Is it "something I personally don't understand or care"?

Things like tabs vs spaces is important, and so is how many spaces an indentation level should take. This affects how editors reformat code, how other people's editors present the code, and even how many lines a commit has and is blamed for a change.

That's why linters are of critical importance to a team, and so is adopting a shared standard and editor config.

The only people who don't understand the importance of a style guide and how to make it a non-issue by enforcing tools to enforce it are those with little to no experience working with software.

View on HN

I have lots of experience working with software.

Linting and style guides are not of "critical importance". No business objective will go unachieved because some checkins use tabs and others use spaces.

Whatever problem style issues might cause can be resolved before lunch by running a formatter and committing the result.

> resolved before lunch

blame.ignoreRevsFile

> Linting and style guides are not of "critical importance".

This is simply false, as attested by the huge volume of comments in this thread by those with actual professional experience working on real-world software projects.

You're also oblivious to the problem domain, because otherwise you'd understand that the critical problems are not whether a space should be at the left or at the right of a symbol, but all the churn that is required to manually address style problems in PRs.

Try to think about the problem. You post a PR that screws up all formatting. It takes time for a team member to review a PR. Once you start to get reviews,you notice comments pointing out failures in complying with a specific style. Whether you go the passive-aggressive path of waiting for any other team member to review your code or you do the right thing and fix the problems you introduced, that requires another round of PR reviews. The time that you take with each iteration is the time your work is delayed to be merged. Now think about how many hours per month you waste just because you can't manage to format your code properly.

I’m not sure if I’m understanding you correctly, but how on earth would a pull request even make it to the review state if it fails to lint in the pipeline?

I sort of agree with GP in that the discussions are a waste of time. I also agree with you that you should simply automate it through tools. Styling doesn’t have to be a democracy or about personal preference, all styles work, it’s all about picking one and then forcing everyone to use it. Of course you do it in a much more involving process than what I make it sound like here, but ultimately someone with decision making powers is going to have to lock down the process so no further time is wasted on it.

Only one place I have worked at had the goal of writing code as if it were from just one person and it was pretty nice, honestly. The diff tool output was easy to understand (not a lot of noise). What made it work was everyone was pretty mature and understood that this was a group effort, and not everyone was going to get their personal itch scratched around brace style, etc.

We did have some outside contractors who didn't get it at first, but after several of their submissions were rejected (with potential financial penalties) they got onboard and followed the guidelines we had sent them. "These people mean it."

Reply on news.ycombinator.com