You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"Yes, certainly!". This was my initial reaction upon encountering the recommendation. However, as I delved deeper into C++ development, engaged in code reviews, and studied existing programs in the language, I started to question whether this recommendation is universally beneficial. Seeking insights from seasoned C++ developers, I discovered that the use of const for local variables is subjective, driven by personal preferences, individual tastes, and even ideological beliefs, rather than being an unequivocally superior practice (in their opinion). Here are a few tips based on these discussions:
const creates a lot of "visual noise" in the code. For example, const int* const pointer = &variable;. This is harder to read than int * pointer = &variable;. But maybe it makes sense to sacrifice readability for something more significant?
"const allows you to monitor in the code which variables are changing and which are not." This is justified in large chunks of code (which it is recommended to avoid), where it is problematic to keep track of everything. But is it really worth inflating the amount of code and sacrificing readability in small methods, where it is easy to keep track of the local variables constancy?
const won't help optimize the code. Modern compilers themselves are able to do static analysis and optimize constants.
Being a lead programmer, in my team I allowed to write const for local variables at will and no longer pay attention to it in code reviews. The colleagues with whom I discussed this issue have the same opinion. Writing const for local variables is a programmer's personal matter.
What's your opinion?
IMHO: In a language, it is better to have a mutable modifier rather than const. Then this problem did not exist at all. But c++ cannot afford such an approach.
Exceptions in Con.1 are clear, I would also add to them "do not use const for the function's return value of simple type". It is useless to write const int func(). But my issue does not address these exceptions. It's about using const for local variables.
"Yes, certainly!". This was my initial reaction upon encountering the recommendation. However, as I delved deeper into C++ development, engaged in code reviews, and studied existing programs in the language, I started to question whether this recommendation is universally beneficial. Seeking insights from seasoned C++ developers, I discovered that the use of
const
for local variables is subjective, driven by personal preferences, individual tastes, and even ideological beliefs, rather than being an unequivocally superior practice (in their opinion). Here are a few tips based on these discussions:const
creates a lot of "visual noise" in the code. For example,const int* const pointer = &variable;
. This is harder to read thanint * pointer = &variable;
. But maybe it makes sense to sacrifice readability for something more significant?const
allows you to monitor in the code which variables are changing and which are not." This is justified in large chunks of code (which it is recommended to avoid), where it is problematic to keep track of everything. But is it really worth inflating the amount of code and sacrificing readability in small methods, where it is easy to keep track of the local variables constancy?const
won't help optimize the code. Modern compilers themselves are able to do static analysis and optimize constants.Being a lead programmer, in my team I allowed to write
const
for local variables at will and no longer pay attention to it in code reviews. The colleagues with whom I discussed this issue have the same opinion. Writingconst
for local variables is a programmer's personal matter.What's your opinion?
IMHO: In a language, it is better to have a
mutable
modifier rather thanconst
. Then this problem did not exist at all. But c++ cannot afford such an approach.P.S. Something similar was discussed in #19.
The text was updated successfully, but these errors were encountered: