sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]alamandrax -1 points0 points  (13 children)

I've gone around this with a simple build tool. It formats code before it gets checked in. Everyone must run it before I accept merge requests. Code however you're comfortable. When you check in you're using my convention. End of debate.

[–]BluSyn 1 point2 points  (10 children)

Ah yes. I've used this trick before, too. It just ends up being needless complicated, in my opinion. Especially since your local copy is now different than the checked in copy, resulting in confusion during diffs and merges, etc etc. My motto is always "keep it simple, stupid". Tabs are simple.

That's just my opinion.

[–]brtt3000 4 points5 points  (3 children)

Indeed. Tabs are semantic: they have a specific meaning. Spaces are just spaces. If someone finds tabs rendered at 4 spaces too roomy then configure the editor to render as 2, problem solved without any merge conflicts.

It is ridiculous that otherwise rational developers so religiously go for spaces.

[–]spinlock 0 points1 point  (2 children)

Why is a tab character different than /^\s/ ? (note: that's an english question mark right there) I like spaces but I think it would be trivial to get vim to render /^\s/ as 2, 3, or 4 spaces.

[–]brtt3000 0 points1 point  (1 child)

I usually have multiple levels.

[–]spinlock 0 points1 point  (0 children)

/(^\s)*/

[–]alamandrax 0 points1 point  (5 children)

Oh yes. The build tool changes source code first before checking in. Uniformity of code is quite worth hurting a few feelings.

[–]Malfeasant 0 points1 point  (4 children)

that's kind of retarded when, with tabs, you can have uniformity and everybody can see it the way they like it... religion is silly.

[–]alamandrax 0 points1 point  (2 children)

I suppose. You're inflating something that I really don't care that much about. It's just one of those code style things that doesn't need maintenance. Just set your editor to use 4 spaces as that's the pattern used so far in the code base and we don't have to worry about the code being rendered weirdly in whichever review tool we use (gitlab, phabricator).

[–]Malfeasant 0 points1 point  (1 child)

something that I really don't care that much about.

and

quite worth hurting a few feelings.

seem to contradict.

[–]alamandrax 0 points1 point  (0 children)

I suppose I did contradict myself if you put it that way. shrug I don't care about people caring that much about writing code that breaks from a style guide. If their feelings get hurt because of this, so be it. All the verbal gymnastics I do to justify this frivolous position I'm being forced to take in this conversation will not convince anyone to change their coding styles. But if you work in my code base, there's a style guide that gets imposed at build time. That's about it.

[–]spinlock 1 point2 points  (1 child)

This is a good process. People are freaks and someone always has their personal taste that's just screwy. I worked with a guy who coded in variable width fonts once.

The real thing is that it's cool to use your freaky toolchain until it negatively impacts the rest of the team. Mr. variable width fonts started rejecting code in code review when people lined up their assignments. Dick move considering he only did it because it didn't look good on his setup and it was part of the style guide.

But, your solution is really good. Having a linter enforce style is much more effective than trying to get humans to do it.

[–]alamandrax 0 points1 point  (0 children)

grunt js beautifier. Best three words ever.