I don't think he's saying that you shouldn't use const (if he is, I vehemently disagree!) just that using it won't make the code faster. It will definitely prevent you, or the next maintenance programmer, from making a lot of dumb mistakes.
I used to use const everywhere and then one day I realised it clutters code and it's never caught a bug for me. I don't personally find it worth the extra time.
(Of course, I use const with pointers on interfaces for read-only referencing).
I know I should use const. I lazily leave it until the end then try to shoe-horn it in. Then it ripples through the code until I give up. Then I hate myself.
I started to use const whenever possible after being familiar with some compiler optimizations and the Haskell pl. The point is knowing how to give the compiler an easier job.
Agreed. I never use const if not required (unfortunately C++ forces you to use it). It is ugly and you're doing work that should be done by the compiler. Moreover, like everything in C++, it doesn't need to be enforced, so it is mostly a moot point.
I am also a const nazi, and occasionally find myself trying to imitate some of its uses elegantly through run time errors or strict naming conventions in other languages. I do understand why many other languages decided not to support it though. There's definitely a few times I've coded myself into a corner and ended up with "const spaghetti", having to do a const_cast or two to free myself and make a deadline.
The article makes it sound a little like you can just slap const everywhere and your code will be better. It does take more time and effort to be const correct, although it's usually worth it.
That is an interesting point of view. I am usually reading code in order to understand what it does (or where it goes wrong) without the author being present, where the proper use of const in declarations can save a lot of time.
Yeah, pretty much agree. The problem of being lazy about constness is that when you finally get your act together and think about it, you'll wind up having these huge "viral" chains of const-fixes to do. The code will be better for it, but you'll wind up changing long chains of things to be const.
I've personally stopped using const in my C and C++ code, except for actually defining constants (in the #define sense). The headaches and complexity it introduces don't seem worth the benefit - you inevitably have to remove the const modifiers from your "const correct" function at some point when it needs to calls out to a non-const function you don't control (one that you know is 'logically const' and pure but doesn't declare it as such in the signature). And as this article demonstrates, the benefits to optimization are not always that great.
And with any kind of STL-like interface or container you're suddenly maintaining two duplicate versions of everything, a non-const version and a const version, likely along with a confusing pile of template metaprogramming and typedefs to support that. Avoiding const altogether is much cleaner.
As Casey Muratori (game programmer) once said, "I haven't typed "const" in over a decade, and I have had literally zero bugs that it would have caught."
I use const frequently, because it helps prevent bugs. When something erroneously mutates immutable data, I want to know that as soon as possible, not months down the road when a corner case gets uncovered. One obvious example of this is thread-safety: you can't write to a const, so the compiler prevents you from introducing data races.
And yeah, sometimes it's annoying write const and non-const versions of the same code. But in my experience, those situations are quite rare and can often be factored out to one-liners; typically, only providing a const version is sufficient.
your question only makes sense if they are using const for performance reasons... which I don't think anyone does. No real reason for using var anymore over let in production code.
I'll still use var in the console for testing stuff.
reply