[taeric]

What about the colleague's who have successfully enshrined non-idiomatic variable naming and space rules in a project?

They seem to have just as much of this argument on their side, as far as consistency and such. Yet I actually loathe the decisions, as it causes a ton of friction with standard tools.

[ryandrake]

The norm seems to be: Conform to what's currently in the code.

Whether it's variable names, your brace style or indenting lengths, it doesn't matter if you think your way is the best, what matters is fitting in with the existing (shared) codebase so it's readable to everyone who has been working on it for the last 5 years.

Same is true for non-style things. If your project is 100K lines of 1998-era "C-with-classes" C++ code, your modern, templated, header-only, lambda-using work of art is going to cause more friction than it helps.

[taeric]

Agreed. Just when you are talking sub 30kloc projects, I feel it would honestly be easier to just do a quick pass reformat in idiomatic style (tool supported being the main point) and then drop the conversation. Having to get every new member to realize that they can not just rely on the tool defaults is... sad.

[Retra]

This is why it is so awesome to encode your conventions into an auto-formatter.

[noblethrasher]

Everything causes friction with respect to something. So you have to examine the merits of the argument.

I, for instance, loathe the prescription that the names of .NET interfaces begin with "I". This is because I realized that once you understand the difference between a “class” and a “type”, then it becomes obvious that everything is an interface (abstraction is just naming things). But, the .NET style guide hinders that understanding since it enjoins you to focus on the little things (classes and interfaces) instead of the big things (types)[1].

So, “code snobbery” is about figuring out what you really want, and then creating cognitive affordances (or eliminating cognitive hinderances) with respect to that.

[1] This is especially apparent when you consider how interfaces and classes are defined in F#.

[tracker1]

More often than not, Abstract Classes, and Interfaces in .Net are more for testability, or code generation than they are actually needed for a working system. I'm not saying they are bad, as I actually like WCF (using a DI framework with convention, not the XML config hell) as well as a lot of the Entity Framework bits.

That said, the more I work with components and smaller services in node.js, the more I enjoy it. It's nice to be able to write meaningful unit tests without several layers of indirection just to be able to write tests.

[picks_at_nits]

I stand by “if the objection has some merit.” If you don’t think it has merit, deploy the counter-snobbery.

Naming seems cut-and-dried, but there are other cases that aren’t so clear cut. What if there are two factions in a team, one of whom are very OO, the other are very functional?

[taeric]

Fights between paradigms is never fun. Especially as that seems to imply there will be fights between evangalists.

[sanderjd]

I find that with naming style, it's hard to go the non-idiomatic route and stay consistent, because you are inevitably interacting with the standard libraries, which are in the idiomatic style, so your non-idiomatic code quickly clashes. Then it's not an argument for one or another idiom, but one for consistency, which is easier to make.

[pekk]

This kind of policy has to be set up front (or at least on a going-forward basis) or it'll never happen. You obviously can't fix this, all you can do is look out for yourself.

Circles of people who all agree to do something wrong and reinforce each other in it are one of humanity's big problems...