[picks_at_nits]

Consider a colleague who constantly objects to non-idiomatic variable name casing (snake_case_in_ruby, camelCaseInJavaScript, dashes-in-lisp, scheme-predicates?, &c.)

When you first get a comment like this, it may feel like friction. After all, the code works. The cost of holding up a deploy and changing your code feels all out of proportion to the benefit. And it’s easy to extrapolate this: “If I get this objection to every pull request, I’ll never get anything done!”

But you don’t need to get this objection to every pull request. If the objection has some merit, no matter how trivial, you can change your naming, and never hear this objection again.

And the entire code base will be a little bit better. Your change is for now, a little bit better is forever, and everyone changing the way they name variables to be a little bit better adds up to a lot better.

And so it is with other forms of code snobs. Although it may feel like it’s not worthwhile to change the code today, if it’s a meritorious objection, then the right thing to do is change it and learn to write it that way the first time around, to develop a habit of writing it that way.

And then everyone will end up being a little bit better. And with every new commit, the code will get better. And that adds up like compound interest into making the code a lot better.

[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...

[jaimefjorge]

"And that adds up like compound interest into making the code a lot better."

Like inverse (or reverse) technical debt. Excellent way of putting why code reviews are important.

I would just add that while improving adds up, it shouldn't cover the fact that blocking the team because of camel case issues is not the best use of time. There are static analysis tools that are free and open source that can do this work.

We are spending between 1/5th to 1/10th of our time reviewing code[1]. Most of the times the disciplined have to carry the burden of being 'that guy' that always has something to say.

1: http://www.quora.com/How-much-per-day-or-week-do-engineers-s...

[tottenhm]

"...non-idiomatic variable name casing (snake_case_in_ruby, camelCaseInJavaScript, dashes-in-lisp, scheme-predicates?, &c.)..."

That usage of "idiomatic" feels idiomatic to me. ;)

(I'd usually bite my tongue about such things, but your nic is picks_at_nits, and the thread is about the virtues of being pedantic...)