2

Our main product is written in C++ MFC and follows the same code standard as MFC.

Now we will start to develop new components, and think about whether we should continue to use the same outdated standard, or whether we should write it with modern C++ according to modern coding standards.

The disadvantage is that there will be a mixture of completely different ways of writing code. How should we do in the interface between the new and the old? What are your experiences about this? What is the right way to go?

magol
  • 201
  • 1
  • 6
  • 2
    Where exactly do you see a conflict between these two? It's hard to give advice when all you tell is is "MFC" and "modern C++", as though these terms immediately convey everything about these two coding "standards". – Nicol Bolas Aug 18 '19 at 13:52
  • Could you add links to: the old MFC coding standard, the new coding standard which you'd like to adopt ? – Nick Alexeev Aug 18 '19 at 14:35
  • The right way to go is to discuss this with the team and how they feel about it, not with strangers from the Internet. FWIW, it will probably make a difference if you just change the naming conventions of your variables, or if by "new coding standard" you have really new language features and libraries in mind, like those functional features, collections from the standard libs, template meta programming etc. – Doc Brown Aug 18 '19 at 14:55
  • 2
    Possible duplicate of [Evolution in coding standards, how do you deal with them?](https://softwareengineering.stackexchange.com/questions/37398/evolution-in-coding-standards-how-do-you-deal-with-them) – Doc Brown Aug 18 '19 at 15:03
  • The reason for my question is because we have started discussing in the project to introduce a code standard, after developing for 15 years completely without any specific standard. But the naming standard has been taken from the MFC. – magol Aug 18 '19 at 19:45
  • What you should try to keep is consistency; It's better to have consistent bad than un-consistent good; If you can put some deadline, and refactor everything to use a new way, you are fine to go; What would suggest is to have new components under a new project, that use the old one; Like that you are not breaking consistency in old one, and improving a code-base in general – Darkves Aug 23 '19 at 12:34

2 Answers2

8

This is where encapsulation pays off.

If you have functionality that's encapsulated in a method or class, that's written in the old MFC style, and you instantiate or call it using new-style code, it will still work, won't it? You don't ever have to look at that old code unless you need to maintain it.

Treat your old code like the black box that it's supposed to be, and you can have it both ways.

To be clear, I think you should leave your old code the way it is (it is tested and proven, after all), and write your new code using your new style. If everything is properly encapsulated, having two code styles in the same code base should not matter at all.

On a case-by-case basis, consider fixing the old-style code gradually so that it conforms to the new style guidelines. You can choose to do this when a class or method is in need of refactoring, or when you need to change its functionality.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
2

The main purpose of standards and patterns is to improve the efficiency with which developers create and interact with code.

They write code in a particular way, and expect to read code expressed in a particular way, and by doing this they reduce the amount of time spent evaluating how best to write code, and reduce the amount of time spent interpreting and gaining an understanding of code that they read.

This is crucial for developers for two reasons. Firstly, code can have all sorts of behaviours (including unintended or unexpected ones) - getting to grips with what exactly any code does (and should do) can take a large amount of effort and experience. It is not just a question of what a single operation does, but how an ensemble of operations or whole system integrates and whether it meets the goals for which it is written.

Secondly, two sets of code that do exactly the same things, or at least have the same external effects and meet the same goals, can be expressed in an almost infinite number of ways. It can take more effort and experience to determine that two pieces of code do the same thing, than it does to write a single new piece of code that is consistent with an understanding you already have.

It is apparent then that not only does code require a large investment to understand it's full behaviour, but that differences in form (even with equivalent behaviour) can require large investments to ascertain that the difference is indeed only in form.

These problems present equally whether you are reading or writing the code, and whether it is your own code you are reading from 6 months ago or whether it is another developer's code you are reading. Except, if you are reading your own code, you might still have a partial recollection of all that went into it.

This is why all developers attempt to leverage patterns and standards of code in their work (including self-imposed ones), because making costly and exhausting investments in understanding, and then embodying the result of this in memorised patterns and standards which are then followed rather slavishly (without a full re-analysis every time), is the only way they can achieve a reasonable pace in writing and reading code (at least, if the code is to be useful and correct).

When do developers talk of changing standards for an existing product?

Usually, when they were not involved from the start, and have no prior investment in the product or in an understanding of its patterns which allow them to work quickly with it. Perhaps, no understanding of any relevant pattern, and want to be sure they are investing wisely (especially in patterns that will be useful in future). Or perhaps, they already have a significant investment in an alternative pattern (perhaps enabled by newer technology or tooling, used elsewhere), and want to get on with writing new code quickly according to that pattern, rather than spending time investing in an apparently obsolete pattern. Or perhaps, they want to invest in a new pattern with a view to creating a new product in future to a better standard - perhaps for a different employer.

Should a standard on an existing product be changed, or be mixed-and-matched? That really depends on an overall impression of why the original standard was adopted, the relative merits of each standard (against the additional complexity and possible integrational challenges introduced), the extent to which the new work is cleanly separated from the old, and indeed perhaps personal career goals which investments in a new standard may suit.

It's a question that is almost impossible to answer in the abstract, except by talking at length about the nature of the problem and things you might want to take into consideration in making a judgment.

Steve
  • 6,998
  • 1
  • 14
  • 24