As time passes I think that one valuable aspect of maintenable and escalable software is to be homogeneous. The same problem should be solved in the same way everywhere in the application. If there is a reason to change how you do something then it should be changed everywhere and if the effort is not worth it then you should continue doing it like in the past.

It is much easier to maintain (and write good code) and application when it's done like this than the other way around, when your first task when modifying a module is to understand how was structured the head of the developer that wrote it.

How can I properly manage and maintain my code base in a large project?

  • 3
    If you can't find any references to consistency as a good practice, you haven't searched hard enough. The great majority of advisers will tell you that consistency across a code base is very important, often more important than the specific way you resolve a particular decision. Commented Mar 12, 2015 at 8:06
  • 1
    Your question is more specific than the title implies. Things that are true about applications might not be as true for software in general. For example when using micro-services architecture implementing services in different languages and technologies is not unreasonable.
    – Den
    Commented Mar 12, 2015 at 11:23
  • @Den: I don't have experience with micro-services but my impression is that a piece of software is much easier to work with if it is developed in a single technology. That way you only need one profile in your team, not several developers mastering different skills. Commented Mar 13, 2015 at 8:47
  • @IgnacioSolerGarcia - correct, it is beneficial to employer, but not to employees (unless they are happy to stop learning).
    – Den
    Commented Mar 13, 2015 at 9:12
  • @Den: honestly, I don't think work is the place to learn. I really think that it is wrong to learn while you work as you will make lots of errors in production code. What if your mechanic was learning while he was fixing your car? (And charging like a senior mechanic) Commented Mar 13, 2015 at 9:19

2 Answers 2


Code style is indeed very important for overall readability, and part of code style means being consistent with said style, even to the extent of respecting the original intentions of the coder that created it or completely redoing it entirely. However, refactoring code is notoriously difficult, and even moreso with projects that have had many project owners over several years.

This is why it is very important that the general practice of you following the style of the rest of the program. Think about it for a second, would you inherit a project with inconsistent coding style and structure had every programmer that worked before you followed this simple rule? No. And since it is easier to add code that follows the general code style of the rest of the program than to refactor, best practice talks about preventative practices, not how best to refactor an already inconsistent project.

That said, you typically don't see articles written about why it is important to be consistent in your code style because it is sort of a given. It would be like writing an article describing why the god object anti-pattern should be avoided whenever possible. Obviously you are likely going to continue your project as you tend to write it, but others may not necessarily do so, so really if you inherit an inconsistent project, it's already too late on that front.

My advice to you would be to get a feel for the different code styles in your program, and pick the one most used in your program and/or the one that is the most straightforward. Then, whenever you need to touch up a class that doesn't quite follow this norm, make a point to ask more time to make the change so that you can make an effort to refactor that class. You'll eventually have something that is consistent throughout, and should another programmer take over your project, we can only hope that they'll continue where you left off.

  • +1. Consistency in existing code always trumps all coding standards.
    – gbjbaanb
    Commented Mar 12, 2015 at 8:44

If you have time to spare to refactor code, then you should spend it DRYing the code rather than homogenising it.

Trying to get all developers in a team to do things the same way is not the problem to solve. The problem is that everyone has a different style in which they can think about code the most logically - that's what you want to optimise - give everyone freedom of expression. What you need to ensure is that each time a developer applies her style it is only used to write code suited to one problem once i.e. DRYness.

  • 1
    I am sorry but I do not see how can help having a team of 10 persons expressing everyone as they want. Won't it be much better thinking on maintenance, extensibility and understanding of the global application to adopt an standard an follow it? Commented Mar 13, 2015 at 8:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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