Hacker News Reader

Comment by Const-me | Hacker News Reader

Some technical decisions aren’t that important.

A trivial example, I have very strong preference on using tabs instead of spaces for indentation. However, I don’t force people on my team to also use tabs because I realize that’s subjective, and doesn’t affect the product we’re developing. These white spaces are ignored by the compiler after all.

The tricky part is estimating consequences of these technical decisions. If you’re more or less confident in your estimations, and you believe the technical decision being made has severe consequences (not just to the product, in the long run development process is equally important), only then is the time to commit.

View on HN

> A trivial example, I have very strong preference on using tabs instead of spaces for indentation. However, I don’t force people on my team to also use tabs because I realize that’s subjective, and doesn’t affect the product we’re developing. These white spaces are ignored by the compiler after all.

Until people start touching each others' code; then it makes sense to pick one or the other and stick with it.

Ironically, when I implemented .editorconfig at my job, (code formatter and checker in CI), I decided that we were going to pick one or the other. I did a little bit of research, and found the silliest little detail that made me pick one over the other.

I won't say what the detail is; but I will say it's a lot easier when CI enforces one approach, and I can run a simple code reformatter if I accidentally violate the rule. Otherwise, it's super-annoying if, every time I get into a new area of the code, sometimes its tabs, and sometimes its spaces.

> then it makes sense to pick one or the other and stick with it.

Oh, being stuck with incumbent decisions.

OMG, the difference between tabs and spaces is so tiny that it's generally inconsequential in modern IDEs.

In our case, where we use .editorconfig and a reformatter, if someone makes a case that we should change, it's trivial to do so.

> Oh, being stuck with incumbent decisions.

I think if you feel that way about tabs vs spaces, the problem isn't "incumbent decisions," the problem is your attitude.

With style, consistency matters more, so ensuring everyone either uses spaces or tabs but not both is helpful. I don't think being willing to commit means you need to decide on which one is used, unless you are a designated tie breaker and others cannot come to a choice.

I think this article still applies there just in a different way. If:

   - you're working on a project with other people and
   - you're at the right level to make such decisions and
   - people compete with different / conflicting formatting

Then it is important that you make A decision. It can be "we're using my preferred style", or "we're using gofmt/rubocop/black/whatever", or something else. But any of them is going to be better than future waste of time in reformatting, merge conflicts and people arguing.

> The tricky part is estimating consequences of these technical decisions.

Estimating or knowing; your tabs vs spaces for example has been tirelessly discussed for years, but the consensus there is that consistency is important, else your git diffs will include tons of churn where tabs are converted to spaces or vice-versa by people's editors.

> However, I don’t force people on my team to also use tabs

Wait a minute. Does that mean you are using mixed tabs and spaces depending on file author? Or are you just saying you start projects using tabs but don’t enforce it for others’ new projects?

Not using python, then, because this causes useless issues.

Reply on news.ycombinator.com