What about source code homogeneity?

Question

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?

Answer 1

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.

Answer 2

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.