[dep_b]

A linter and code conventions are a way to make code more consistent and easier to switch between. At times it becomes hard to see what code you wrote and what somebody else wrote, which is a good thing. If I open a file and everything "just feels wrong" but I can't change it because enforcing my personal preferences are just my personal preferences is just making things worse that really takes some valuable energy away I could use for actually improving things. But I can get used to a coding guideline that's not 100% my preference but a well enforced and consistent one. Knowing that if I fix indenting and naming the fix will not enrage someone else.

[dasmoth]

At times it becomes hard to see what code you wrote and what somebody else wrote, which is a good thing.

I suspect this is the big point of disagreement between lint-advocates and many of those who are dubious. I generally don’t see big wins from collectivising code, and on the who prefer to treat people I’m working with as individuals who can be interacted with 1:1 vs an amorphous “the team” writing “the codebase”.

[dep_b]

Usually there’s a style that’s mandated by large authorities like C# formatting is mandated by Microsoft and JetBrains. Copying their style gets you there for 80%. The rest is whatever you agree on and usually not something that bothers me.

If you’re the guy that thinks having a 300 line function in an 8000 line class is just an individual way of expressing yourself you’ll have to fight me.

If you think real tabs is better than 4 spaces I shrug and let you have it your way.

[dasmoth]

The fact that you’ve named an IDE vendor rather emphasises that there is a substantial gray area. By no means everyone wants to use an IDE (let alone that specific one...)

[dep_b]

True. But for Objective-C I often used the NY Times style guide. Just whatever the one is that is the most complete and most easy to maintain really. But I notice with C# that if I copy-paste reasonably fresh code from Stack Overflow to VS + RS I sometimes get zero warnings because the other programmer uses exactly the same toolchain and style. Same goes for Python PEP8 in PyCharm. Personally I like the idea of having a strong similarity in code style within an ecosystem, especially when dealing with libraries that more or less follow the same conventions as the code that I wrote myself.