Is there such a thing as too much uniformity? Where I work we of course have standards including naming conventions, architectures, frameworks to leverage etc. However lately there has been a lot of critiquing of things I would consider more style.

For example writing if statements in multiple lines vs one line, using the c# ?? null-coalescing operator instead of say == null, amounts of spacing for indentations etc.

It seems to me this starts getting more into a personal style choice and doesn't need to be uniform across a team or company. What one person thinks reads more clearly another may not. Is there some value to this "extra" uniformity?

  • 2
    Hi Gratzy, Programmers.SE is not a discussion board; we're here to solve real problems you might be facing. Do you have an actual problem you're trying to solve? If so, can you reword your question to keep the answers constructive and out of the pitfalls of becoming a discussion? – user8 Jan 21 '11 at 20:10
  • 1
    @Gratzy to put it another way, given a situation you personally are facing, what would be the criteria for a correct answer? – user8 Jan 21 '11 at 20:14
  • 2
    @Mark Trapp according to the FAQ these are the criteria for a question All subjective questions are expected to be constructive. How do we define that? Constructive subjective questions … 1. inspire answers that explain “why” and “how”. 2. tend to have long, not short, answers. 3. have a constructive, fair, and impartial tone. 4. invite sharing experiences over opinions. 5. insist that opinion be backed up with facts and references. 6. are more than just mindless social fun. I believe my question covers the first 4 at the very least – Gratzy Jan 21 '11 at 20:20
  • 2
    @Gratzy also from the FAQ: "You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page." – user8 Jan 21 '11 at 20:23
  • 2
    @Mark Trapp I've already stated criteria for an acceptable answer and yes as I've said this is an actual problem and quite frankly from the interest in the question and the answers I would say others agree. – Gratzy Jan 21 '11 at 20:25

Uniformity is not a problem (it's good) but rigidity or inflexibility can be. If in striving for uniformity you become dogmatic then the harm you are doing to the team may be greater than the good that comes from the (possibly) resulting uniformity.

It's best just to set basic style for the most important things (naming and capitalization standards, indentation, new-lines and bracket placement, etc.), set recommendations for less important things (if statement format, other whitespace around parentheses, etc.), and then not worry about the rest.

  • 1
    I've been there – user2567 Jan 21 '11 at 19:04
  • +1, said what I meant, but better! – FrustratedWithFormsDesigner Jan 21 '11 at 19:07
  • @Pierre is that why you are freelance now? :) – Nicole Jan 21 '11 at 21:37
  • not really, but I've meet somany obsessional people about guidelines. It's scary how it can be extreme. I think you defined the limit pretty well. – user2567 Jan 21 '11 at 21:43

When potentially dozens of people are working on a project over the years of its lifespan, it sometimes gets confusing when you have to jump styles. Imagine reading a book where different chapters are written by different authors who only somewhat maintain writing style. It's possible, but it's annoying.

Most IDEs can enforce styles these days, so if necessary you can distribute (as a part of the project source code) an IDE preferences file that specifies the chosen coding style and have everyone install it and use it to format the code they're writing. I bet there's even ways to have code reformatted/styled on check-in (though I haven't had to investigate this yet).

  • Yeah, you could probably stick an ant script in there somewhere. – Michael K Jan 21 '11 at 19:11
  • 1
    IntelliJ, at least, has an option to reformat code before checkin. – Nicole Jan 21 '11 at 19:52

One case of over-uniformity I've seen is to have a single standard that applies to all programming languages regardless of appropriateness:

  • Discouraging goto even in languages like C without try...catch.
  • Using InitialCaps names (as in Microsoft's MFC and C#) in JavaScript where the standard library is initialLowerCase.

I don't think there is such a thing as too much uniformity. However, I often find that too much SPECIFICITY in coding standards. The benefits of everyone putting the opening brace on a separate line are dubious at best and don't outweigh the time spent arguing about it or fixing cosmetic issues in code.

  • 2
    @Tungano I couldn't agree more. The paradox of coding standards is that they are well worth having, but they aren't worth arguing about. – Charles E. Grant Jan 21 '11 at 19:22
  • 3
    I don't see how forcing a particular style down a programmer's throat is going to help you avoid those arguments. In fact, I'd argue that making a programmer adapt to a style they don't like ENCOURAGES those arguments, or at least resentment. – JohnFx Jan 21 '11 at 19:36
  • 1
    @JohnFx, because most programmers will realize that consistency of style makes a much bigger contribution to code quality and maintainability then any particular choice of style. In my experience you can do a quick nose count of the team, see what people like and dislike, and quickly come to a consensus. Occasionally someone will have a peculiar bugaboo and you accommodate them, then they yield on somebody else's bugaboo. If I find myself haranguing the team for five minutes on why camel-case is evil, I just give it up and yield as a test of my personal flexibility. – Charles E. Grant Jan 22 '11 at 3:24
  • 1
    I'd posit, that most programmers THINK that consistency of style makes such a big contribution, but it really doesn't. It seems like it ought to, it is annoying to look at code that doesn't match your pet style, and going through a block of code "cleaning it up" for minor cosmetic issues is a good way to procrastinate. Look, I used to be on that bandwagon too until I realized I was focusing on gold plating and not the deliverable. – JohnFx Jan 22 '11 at 15:27
  • 1
    I work with code from our German team, a couple of OSS projects and some ancient code we have as well as our current stuff. Some is C, some C++, some C#. So I have to work with several differing code styles all the time. When you do that, you realise how petty the style guidelines that get mandated in standards are. If I can switch from one to another project, I can handle someone putting their {} in different places. This is why I think the only standard worth a damn is the one with 1 rule: "consistency within each project". – gbjbaanb Jan 28 '12 at 16:01

I'd have 2 arguments for the uniformity:

  • Promoting collective ownership. That someone can go edit the code of someone else without fearing that someone's "baby" is about to be hurt by the change. A kind of "We're all in this together" mentality.

  • Ease of adding to it. If something has already been done somewhere else then this can be taken and re-used possibly. Certain conventions can help make things easier to read or change sometimes so this is another benefit to my mind.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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