Take the 2-minute tour ×

Recently I had a discussion with a colleague regarding code style. He was arguing that your usage of APIs and the general patterns you are using should be as similar as possible with the surrounding code, if not with the the codebase as a whole, just as you would with code appearance (brace positioning, capitalisation etc). For example if I were adding a method to a DAO class in C# I would try to use LINQ where appropriate to help make my code clean and easy to maintain, even if none of the other methods in that class were using it. However, my colleague would argue that I should not use it in that instance because it would be against the existing style of that class and thus harder to understand.

At first I found his position rather extreme, but after thinking it over for a while I am beginning to see his point. With the hypothetical LINQ example, perhaps this class doesn't contain it because my colleagues are unfamiliar with LINQ? If so, wouldn't my code be more maintainable for my fellow developers if I didn't use it? On the other hand, if I truly believe that using such a technique would result in cleaner code, then shouldn't I use it even if it differs drastically from the surrounding code?

I think that the crux of my colleague's argument is that if we all go about implementing similar functionality in a codebase in different ways, and we each think that our way is "best", then in the end the code as a whole just gets harder to understand. However at the moment I still think that if we blindly follow the existing code too much then the quality will just slowly rot over time.

So, to what extent are patterns part of code style, and where should we draw the line between staying consistent and making improvements?

share|improve this question
So how would the code quality ever improve, if everyone restricted themselves to the "bad" way? –  Izkata Mar 15 '13 at 12:16
When you write LINQ don't you mean LINQ to SQL? If yes then I could agree with your friend. If you are talking about LINQ then I don't agree with him. Everybody has to be familiar with LINQ these days. It's not their choice. They are payed to be familiar. –  Peri Mar 21 '13 at 20:28
@Peri I meant just basic LINQ - I guess my example should have been about working with IEnumerables rather than a DAO. –  Robert Johnson Mar 21 '13 at 21:56
ICYMI - Dilbert comic on this very topic: dilbert.com/strips/2013-09-21 –  Jim Bethancourt Oct 11 '13 at 19:53

8 Answers 8

up vote 48 down vote accepted

To give a more general answer:

In a case like this, you have two programming "best practices" that are opposed to each other: code consistency is important, but so is choosing the best possible method to accomplish your task. There is no one correct answer to this dilemma; it depends on a couple factors:

  • How beneficial is the "correct" way?

    • Sometimes the new and improved best practice will dramatically increase performance, eliminate bugs, be far easier to program, etc. In such a case, I would lean heavily toward using the new method. On the other hand, the "correct way" may be little more than syntactic sugar, or an agreed idiomatic method of doing something that is not actually superior. In that case, code consistency is probably more important.
  • How big of a problem would inconsistency create?

    • How interconnected is the new code with legacy code? Is your new code part of a library? Does it create an object that gets passed to many parts of the program? In cases like these, consistency is very important. Using a new API, or a new way of doing things in general, might create subtly different results that break assumptions elsewhere in your program. On the other hand, if you are writing a fairly isolated piece of code, inconsistency is less likely to be a problem.
    • How large and how mature is your code base? How many developers need to understand it and work on it? Agreed-upon, consistent standards are much more important for larger projects.
    • Does the code need to run in older environments that may not support the latest features?

Based on the balance of these issues, you have to make the right choice about which route to take. I personally see little value in consistency for consistency's sake, and would prefer to use the latest, best methods unless there is a significant cost to do so.

Of course, there is a third option: rewriting the existing code so that it uses the best methods and is consistent. There are times when this is necessary, but it comes with a high cost.

share|improve this answer
Very good and balanced answer (+1). In my experience a team can be more productive if all agree on a relatively small set of well-understood idioms than if each team member is free to use new and different idioms that other team members might find difficult to understand. One small point regarding the statement "rewriting the existing code so that it uses the latest practices and is consistent": "latest" does not automatically imply "better". One must always decide from case to case. –  Giorgio Mar 15 '13 at 11:11
@Giorgio, thanks for the feedback; I tweaked the language of the final point. –  dan1111 Mar 15 '13 at 11:25
Good answer and good comment from Giorgio. Maybe worth considering that in this example, depending on the team/culture, it’s possible to have a coordinated team adoption rather than starting alone. This reduces some of the risk around maintenance (as everyone's on board). (i.e. place more emphasis on the team's actual skills at the moment, rather than the code they've written in the past.) –  Matt Mar 15 '13 at 13:33
+1. Agreed, a thorough and balanced answer - good consideration of a variety of scenarios. Again, good comment from Giorgio. –  Robert Johnson Mar 15 '13 at 16:34
Regarding the adoption of new idioms, technologies: I would consider the beginning of a new project as a good point to introduce new stuff. Afterwards, during the whole project's duration, the style of the code should be kept as consistent as possible. I recently had to dig out some 5-year old code and I was very glad that I could still find my way through that code because the whole team adhered to a common architecture and set of idioms that we had agreed upon (not without struggle!) at the beginning of the project. –  Giorgio Jun 1 '13 at 10:01

Staying consistent has little value in my perspective; continuously making improvements is a must.

Your colleague's position really impedes innovation. The consistency argument gets you into a situation where you can use, for example, LINQ only if you migrate all code to use LINQ. And well, we don't have time for this, do we?

I'd rather have inconsistency where some code is still doing foreach over ArrayLists and other parts use LINQ on IEnumerable<T>, instead of sticking to the oldest way of doing things until the end of time.

It's your colleagues' responsibility to stay relevant and learn new ways of doing things.

share|improve this answer
"It's your colleagues responsibility to stay relevant and learn new ways of doing things.": A possibility is to use new idioms and libraries in new code (new modules) and keep a consistent style in legacy code. –  Giorgio Mar 15 '13 at 11:02

API consistency is very important, both for public and internal APIs.

Code formatting consistency is important, and should ideally be enforced by automatic formatting tool with same formatting rules for everybody. Makes living with shared version-controlled codebase easier.

Naming conventions should be consistent, also for things like local variables etc.

Static analysis tools should be used to enforce certain other conventions and good practices (but do not blindly follow the defaults of any such tool, the defaults can sometimes border on insane), though if something demands it, don't be afraid to disable some check (usually with a directive inside a comment) temporarily, if you can justify it.

What happens inside functions/methods, apart from what is listed above, doesn't need to be consistent in any way, as long as it is good code on its own. Good, understandable, well commented code is very important, but after that, if compiler and static analysis tools think it's consistent code, that's consistent enough.

About new language features such as LINQ (well, that's not exactly new), the only thing that needs to be considered is, will new enough version of language/libraries be in use everywhere where the code will be used? If in doubt, stick to features which are known to be compatible. This doesn't of course prevent you from pushing a version upgrade throughout the system, so you can start using the new nice things.

And every developer working with code should keep up to date, so any .NET developer should know LINQ, and if they don't they should be forced to learn, for their own good (you never know when you will be looking for a new job in this business, for one reason or another).

share|improve this answer


The C# language is still evolving. If people didn't learn the changes from C# 1, they would be missing out on:

  • Generics
  • Partials
  • Anonymous methods
  • Iterators
  • Nullable types
  • Auto-properties
  • Anonymous types
  • Extension methods
  • Ling
  • Lambdas
  • Asynchronous methods

This is just a small selection of common features found at the Wikipedia article. The point I'm making is that if the developers don't learn, the codebase will stay in a vacuum. One would hope that your developers do continually improve and the code base evolves, supported by a complete test suite. Do you remember how bad it was with .NET 1 to manually implement properties.

Linq makes life easier. Use it where you can. You might motivate your team members.


Improvements are gradual. To me, it makes no sense to keep old style code which is less readable and potentially less maintainable. Your team members should at least be able to work out what's going on, even if they can't write it.

share|improve this answer
I agree wholeheartedly with what you're saying, but my question is less about new language features and developers' responsibility to learn them, but rather the more general question of solving similar problems in different ways within a relatively small area of a codebase. I mentioned LINQ because it is a good example of using a different way of solving a problem. My colleague is happy to use new language features, but only if they don't go against the grain of the code he is working on. –  Robert Johnson Mar 15 '13 at 9:54
@RobertJohnson I would point out to your colleague then that maintainability trumps consistency, so even if something "goes against the grain" of existing code, if its more maintainable, you should do it. I doubt using the old stay DAO would be more maintainable than Linq. –  Andy Mar 15 '13 at 12:08

You should be consistent, but not necessarily with the old code. That is, your team should agree on the right way of doing something, and use that way whenever new code is written or substantial changes are made.

That way, you reap most of the benefits of consistency (in particular, it won't matter who writes the code), but can still improve if the team sees a clear benefit by doing things another way.

In an ideal world, we would rewrite all old code to conform to the new right way. While this is not economically viable, it should make technical sense (or else, the new way is not a better way), and your long term plan should be to upgrade it. If that is not worth it, don't bother with the new way. Put differently, there must be a clear advantage to the new way to consider declaring it the right one.

share|improve this answer

I think it is important to follow a code style in a project eg. naming conventions, indentations etc.

I do not agree that you should be limited from using new language constructs or design patterns simply because your colleagues do not understand them, or they haven't been used in the project before.

Of course these things should have good reasons for using them eg. performance or brevity, if appropriate.

share|improve this answer
What's was the minus for? –  jmo21 Mar 16 '13 at 19:55

We have regular, fairly informal, technical meetings which any one of us can run. If we find a new technique we present it at the meeting. You generally get a good feeling of how well the idea is accepted and understood by your colleagues. This helps you to decide whether it is wise to include it in your code, helps others to decipher it if you do and also establishes the 'go to' person if others need help with that style. If no one reinvented the wheel we'd still be dragging stuff around on logs.

share|improve this answer
What's was the downvote for? –  Ant Apr 19 '13 at 15:47
I was not the downvoter, but this doesn't really seem targeted to the question. It is a team process that could be applied to anything, rather than a discussion of coding style issues. Also, don't you mean "invented the wheel" rather than "reinvented the wheel"? –  dan1111 Jun 3 '13 at 9:49
I suppose it's semantics whether a log is a type of wheel or not but it rotates, reduces friction, has a surface that is in successive contact with the ground and is round. I am sure there are better examples of what I mean - I'll leave that as an exercise for the reader. –  Ant May 29 at 10:25

I would be extremely careful blindly following current design patterns. Of course, when there is no appreciable downside, one should always attempt to follow similar patterns across the code base.

However, it's far too easy to get into circumstances where the majority of developers feel as though it's "best practice" to following the existing bad patterns leading to situations where good developers are writing bad, unmaintainable code.

On the other hand, consistency is important. When dealing with enormous code bases, it's extremely useful to try to follow similar patterns so that even though developers have not read every inch of the code base, they know what to expect.

Therefore, I believe it's best to establish and update guidelines about what patterns developers should follow if able. This way, any new code is consistent with other new code.

share|improve this answer

protected by maple_shaft Mar 15 '13 at 13:28


Would you like to answer one of these unanswered questions instead?
