Do you have a find/replace list of C/C++ code improvements that doesn't cause side effects?

Question

Time after time you have to work with code that's not as safe as you would like it to be. Either that's someone elses code, or something you wrote at 3am 5 years ago, but it happens.

And in those cases it would be good to make that code a little bit safer and more typing-error prone.

At the same time, you want to avoid extensive testing, and if code is not covered with unit-tests, well, let's be honest, even if it is, you can't be sure you won't break anything when doing most refactoring things.

So, what I'm wondering is, what would be a shortlist for C/C++ code that can be automated to almost "find/replace all" that would make the code safer, without having high risk of changing the programs behavior.

Few things that came to my mind:

• Make all member functions const
• Make all arguments for internally linked functions const
• Remove all C style casts and replace them with C++ style casts on errors
• Turn most macros into inline functions or templates
• Change enums to typed enums

But most of them would need a recompile and manual verifications Do you have other candidates, and maybe even safer ones?

• mouviciel: if it ain't broke, don't fix it - Your manager wouldn't appreciate that you spend his money on something useless from his point of view.
• Coder: @mouviciel: Ok, so you have a unsafe, crappy, unextendable code, and you suggest to keep spending weeks on trying to figure out how to work around deficiencies and how not to make yet another bug because raw pointers to raw data are spread everywhere and processed in 50 different ways? Instead of slowly migrating it to safer and more extensible design?
• mouviciel: No, I just say that most managers perceive the short term cost of reducing technical debt but not its long term benefit. The ones who understand blame developers for writing crappy code in the first place.
• Coder: @mouviciel: In the end it's you who will have to work with the code for a long time. If you're matching the deadlines it's a very good decision to improve code you'll have to work day to day. If the changes are safe and will not cause side effects. If they do, there is a lot of weighting to do before touching anything.
• mouviciel: Neither me nor the manager: Once the code is delivered to the client, everybody on the project is dispatched on another project and it is up to the maintenance team to deal with it (if the client subscribed to that service of course).

Answer 1

I would personally say there is no such list.

There are many kinds of syntax that have some "safer equivalent" but for which there are too many justifiable reasons to use to say that it should be replaced with the "safer" code.

For example, not all member functions should be const, and there are cases where you don't want to do such a thing. There are good reasons for not making parameters to functions const, just as there are reasons to make them const. There are cases where a function-like macro is actually a code-generating macro or where turning it into an inline function isn't justified. There may be reasons to prefer a "plain" enum over a typed enum.

There aren't enough hard-and-fast rules, I think, to even consider any candidates.

There are some general rules: Prefer references over pointers; avoid the use of new when possible; avoid writing operator overloads; and so on. But there are exceptions to all of these "rules" and there are arguments for ignoring them.

Most of this is a matter of style. Use whatever style is appropriate.

• Ryathal: if a list did exist, then 90% of the material on maintenance and refactoring wouldn't exist.
• Max: @greyfade Curious, what do you mean by plain vs typed enum?
• greyfade: @Max: C++11 added strongly-typed enums called enum classes. Normally, enum is equivalent to a (I believe) int type. This new feature eliminates some of the problems with "untyped" enums.

Answer 2

Pointer arithmetic, in the general case. Not all pointer arithmetic is bad but the vast majority of it should be well encapsulated and never shown to the user. I'd also flag up calls to new and delete as worthy of a second look.

• Coder: Do you have any examples of transformations that are mostly safe and typing-error free?

Answer 3

• fix all warnings
• compile with maximum warning level
• remove all c-style casts
• remove all unnecessary macros
• try to get 100% code coverage with good unit tests and code quality