Him: "No developer worth his salt puts each of his brackets on a new line."

Me: "I mean... I agree it's uglier but your whitespace commit means we git blame you for everything."

Him (upset): "You BLAME me? I'm sorry I have standards."

Me: "Not blame blame, git blame like the history view of the-"

....too late he reverts his commit and hates me for life.

I wasn't even disagreeing, I was trying to explain git blame. :(

@irene It's the sort of thing I'm glad we have linters for these days.

So many people turn off their theoretically enforced autoformatter at work that I keep having to unselect every file I've changed and un-changed every time I commit, because it does lots of formatting every time I save. The other option would be to turn off my formatter, too, but no! I won't turn to the dark side, no matter how strong it is!

https://prettier.io + precommit hook solves this permanently. No more never-ending discussions about code style and meaninglessness git blame / diff.

@Fabian @Commodore

Using your own autoformatter is rude. Using an autoformatter with an agreed upon company ruleset committed into a repo is an excellent idea.

The most important consideration is not whether to use newlined brackets or tabs or whatever, but to have everyone conform to settings which everyone can at least live with.

And to not have commits continuously changing the work of someone else's autoformatter, just because you both have a slightly different ruleset.

@bittersweet yes of course, it only make sense if everyone uses it, otherwise it's still a pointless commit war with a bit more automation

Nothing is more fun than searching through a commit where every line has changed because that one developer who refuses to follow the team standard has changed all tabs to whitespaces (or vice versa) or altered the braces.

It doesn't really matter what the format standards are (within reason), what is more important is that everyone follows the same standards.

@bittersweet That's why I said "theoretically enforced". In theory everybody in the department should use the same Eclipse download (custom with plugins, settings, etc.) and the latest autoformatter version from the intranet.

@Fabian Eclipse, intranet... Please stop using such foul language! 🤣

@Fabian what year do you live in my good sir?

@Robinha Ugh. Flashbacks to labs project. We all decided before starting to use Flake8 as our Python linter and Black as our formatter. And then one member of the three-person team “broke” their install of both and didn’t bother fixing it... near the beginning of the project. *eye twitch*. Before we figured out pre-commit hooks.

Needless to say, every time I talk to someone about to enter labs, the first piece of advice I give them is to look into hooks.

Unrelatedly, I’m one of those horrible people that don’t put every brace on a new line:

int example () {
while (sleeping) {
cat steals pillow
occasionally kicks me in the face
I am so tired
}
return 0
}

@Commodore The codebase is from the last millenium, certainly.

@Robinha Tabs are also whitespace.

I love how this thread became about brackets and not about git blame vs actual blame (the point of the story)...

you do you, devRanters. You do you. :)

@stisch I mean, I only look at the fit blame when there’s something worth blaming someone for...

@irene In that department it was not my choice. And when I switched departments, I didn't want to set IntelliJ up, because just getting access to their repository already took multiple days and didn't fully work, a switch of devEnvs would have taken even longer probably. And now I'm back at the first department.

Also, IntelliJ has no way to see all warnings. Here's a report that can be voted on: https://youtrack.jetbrains.com/issu...

@AmyShackles I am with you on this. Looks perfect.

Moreover, diff tools can be configured to ignore whitespaces from the diff they produce