Further cleanup

[stefanos82]

No description provided.

[aristocratos]

Looks good 👍🏼

[imwints]

@stefanos82
@aristocratos
But why would we do this? Why allow variables, which are not changing, to be mutated? You should keep all those bools as const if they're not reassigned in the function bodies.

[stefanos82]

But why would we do this? Why allow variables, which are not changing, to be mutated? You should keep all those bools as const if they're not reassigned in the function bodies.

No need to, because false and true are prvalues of type bool; therefore the compiler will optimize their const-ness out.

If we are dealing with actual objects, such as classes then yes, it would have played a major role to retain our const type qualifier, even though nowadays with move semantics, you don't always need to deal with const someObject&, thus you can reduce memory usage just by move a lot of data around with move semantics.

Anyway, long story short, the optimizer was already discarding the const type qualifier from bool variables and decided to clean it a bit; that's it, really.

[imwints]

I hope this PR was not done for any performance gains. That's not what this is about. Putting const on a trivial type has no speed up effect at all, this should be clear.

This is about readability and maintainability.

https://stackoverflow.com/questions/22285773/use-const-wherever-possible-in-c/22285981#22285981

If you find ordinary type safety helps you get systems correct (it does; especially in large systems), you'll find const correctness helps also.

You should use const when you want to be sure not to change variable accidentally or intentionally. Some constants (globals and class static, strings & integers, but not variables with nontrivial constructor) can be placed in read-only parts of the executable, therefore result in segmentation fault if you try to write to it.

and

[...] You should be using const whereever it is possible and makes sense.

From here:

const correctness can't improve performance because const_cast and mutable are in the language, and allow code to conformingly break the rules. [...]

That all said, const correctness is a good thing with respect to maintainability. [...]

Don't use const for performance reasons. Use it for maintainability reasons.

Something more legitimate might be IsoCPP:

What is “const correctness”?
A good thing. It means using the keyword const to prevent const objects from getting mutated. [...]

Should I try to get things const correct “sooner” or “later”?
At the very, very, very beginning.
Back-patching const correctness results in a snowball effect: every const you add “over here” requires four more to be added “over there.”
Add const early and often.

and another opinion right behind:

Doom's code is fairly rigid, although not rigid enough in my opinion with respect to const. Const serves several purposes which I believe too many programmers ignore. My rule is "everything should always be const unless it can't be". I wish all variables in C++ were const by default. Doom almost always sticks to a "no in-out" parameter policy; meaning all parameters to a function are either input or output never both. This makes it much easier to understand what's happening with a variable when you pass it to a function.

https://github.com/cpp-best-practices/cppbestpractices/blob/master/04-Considering_Safety.md:

const tells the compiler that a variable or method is immutable. This helps the compiler optimize the code and helps the developer know if a function has a side effect.

It is for the developer to make fewer mistakes and having a better time reading the code and understanding it.

[stefanos82]

Since you are so pedantic and most probably have years of professional experience, by all means feel free to PR anytime and help this project with your expertise.

Cheers 👍