I've been with my software team for about three years now, and just recently I brought up the concept of variable naming conventions (across all languages, but C#/VB.Net specifically).

We really don't have any solid naming conventions. I was met with serious resistance - so what?, does it really matter?, blank stares, etc.

I was able to get the others to agree to at least be consistent on a given code file (not ideal, but with this group, any standards that is based around anything other than SQL is a step forward).

My question is this - I've always received resistance to developing standards.

  • Should I just stop pushing standards and accept the fact that everyone seems to be doing their own thing when they code?

closed as primarily opinion-based by Robert Harvey, user40980, Telastyn, gnat, jwenting Sep 3 '14 at 8:04

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 7
    Microsoft has already done the leg work for you. Why not simply adopt their standards? Every development team should have a coding standard. Everyone on the team should follow it, and it should be enforced by a code formatter or some sort of linting program. There are many reasons why this is a good thing; consistency is the most important one. Not being regarded as amateurs is another. – Robert Harvey Sep 2 '14 at 20:50
  • 3
    Most programmers are immersed in solving real problems. They just don't want to hear about how they're notPushingTheShiftKeyEnoughForMicrosoftsLiking. Over time, I've come to believe that the best variable names look-like-this (which is a very easy standard to type and to read); in languages where that's not allowed, I think programmers should mostly be left to their own devices in dealing with this deficiency. I'm not advocating complete chaos, but most people who actually get paid to code are, in my experience, responsible enough to avoid really bad names on their own. – user1172763 Sep 2 '14 at 22:32
  • 1
    @RobertHarvey Microsoft also preached Hungarian notation once upon a time. – RubberDuck Sep 2 '14 at 22:39
  • 2
    @user1172763: Following the shop's coding standards requires the least amount of time and effort, and assures consistency within the project. It doesn't have to be the Microsoft standard, but it does need to be the same standard for everyone on the project. It's not about your personal preferences. – Robert Harvey Sep 2 '14 at 23:02
  • 4
    @user1172763 I completely disagree with you. It shows that you do not pay enough attention to detail if you use inconsistent or incorrect naming conventions. How could anyone trust your code if you can't even get something basic like using the correct naming conventions? – Stephen Sep 3 '14 at 3:44

Don't quit yet. Try the following first.

Sell them the idea differently. Sell them the idea as "code quality".

If you are the boss:

  • Tell them that they need to improve the quality of their code.
  • Tell them that the naming convention is the major aspect to be considered in the first phase.
  • Tell them that code quality is going to be considered in their performance appraisal.

If you are only their peer:

  • Tell them they don't have to change the code that is already done, but apply the conventions in the new code they write.
  • Use the convention yourself.
  • Clarify that you are not inventing some in-house convention but using the universally-accepted convention of any given language, the one the official documentation of the language uses.
  • Prepare a presentation about the benefits of adopting a naming convention.
  • Talk about the collective ownership of code. They shouldn't apply personal criteria to code that is everyone's to maintain.
  • Plot/print a poster-sized naming convention cheat-sheet and display it in your cubicle. Offer to plot/print a copy for whomever shows interest.

Do you use unit tests ?

  • Refactor mercilessly whenever you feel like it. Unit tests will have your back.

If nothing works:

  • Be faithful to yourself and continue to provide an example.
  • Remember work is only a part of life. Pursue other, more worthy aims.

Not the answer you're looking for? Browse other questions tagged or ask your own question.