Is it worth to insert `const`-correctness_问答_开发者

I'm currently confronted with a C++ project written by some senior programmers consi开发者_运维知识库sting of about 400 files and 200 classes.

The code is well elaborated, works fine and stable.

While I'm adding some features, for me it is just ordinary practice to take care about const-correctness.

But if I start to declare my new member functions const, there is no end with adapting old code in order make things work.

Should I invest the amount of time to introduce const-correctness into this code?
Even worse, I have to touch and alter the old mature code and explain to the seniors what I did during the code review. Is it worth it?

Const correctness is a kind of additional layer over static typing that is meant to make it easier to develop mature, reliable and robust code. You say that you already have the latter. In that case, enforcing const correctness in such codebase doesn't seem to have significant, added value from the pragmatic point of view.

Should I invest the amount of time to introduce const-correctness into this code?

If you feel that you can get it all done in a reasonable time, sure. const-correctness is a good thing, so if you can adjust the codebase to employ it properly then that can never be bad.

It all comes down to how much time you have available and what else you could be doing instead, which is more about project management and more appropriate on programmers.SE.

Even worse, I have to touch and alter the old mature code and explain to the seniors what I did during the code review. Is it worth it?

It's certainly worth it for them (and, by extension, to everybody else). It sounds like they will learn a lot in code review, which is fantastic!

Edit

As molbdnilo rightly points out, this is a big change and you should definitely have a group discussion about it before starting. This would be more appropriate than leaving it to code review in two weeks' time, when you've already done it.

It's worth the effort... Unless you have more important things to do.

It's a difficult issue. Retrofitting const correctness is a non-trivial job (as you're noticing). If the code is otherwise clean and maintainable, it probably shouldn't be undertaken lightly. On the other hand, const correctness is almost essential in some cases—or would be, if all compilers enforced the rule about not initializing a reference to non-const with a temporary.

If you're not the sole owner of the code, the thing to do would be to discuss the issue with the other people involved, decide in common whether it is important, and program the time necessary to do it if it is deemed important. What you shouldn't do is just start introducing it on your own, as a "side effect" of the changes you were mandated to do. It's a project level decision.

yes and yes. Const correctness is a Good Thing for a number of reasons, amongst which that it helps prevents bugs. I actually already discovered bugs while applying const correctness in a situation similar to yours.

Yes. Once you get over the hurdle of converting your current code to be const correct it becomes second nature.

Also if you start to follow a spec like MISRA it requires your code to be const correct (amongst many other things).

There are two technical steps in enforcing const-correctness.

Before you start though, you need to involve your team members, and explain the benefits of const-correctness. If you cannot convince your team mates, it's not really worth launching into this...

Now, since we're on StackOverflow, and not SE, I'd rather concentrate on the technical approach.

The two steps are drawn from the fact that:

you cannot call a non-const function on a const object
you can call a const function on a non-`const object

Therefore:

Tag as const those functions who are
const-ify the variable/parameters/attributes

The first step is non-invasive and already yields its own benefits, since it will prevent accidental modifications of the inner attributes of a class within the tagged method.

Even if you face slight resistance in your team, you can still tag the methods you develop or touch as const without any hindrance for the rest of the team.