To my understanding comments are ignored by compliers and runtimes having them makes no difference when the code is actually running. I may be wrong on this point though.
I was referring to this line
If it’s not immediately obvious what your code does by reading it, you should rewrite it so it is
Code that is written for human readability omits an amount of optimisations languages have in compilers, jits, and runtimes. As code is read by machines several orders of magnitude more then a human, why make the code 20 to 30% slower for a computer to read just so an engineer can read it 40% faster?
With that being said, not all code needs to be optimised that hard. There are times where you don’t need that 20 to 30% increase in application runtime and writing code that is readable or “self documenting” works well enough.
We’re kinda breaking from the shitposting theme here, but this is good discussion
Honestly unless you’re writing DSP or 3D engine code, micro-optimisations are an absolute waste of time. Either you’re working in a low enough level language that the compiler is going to do a better job than you anyway or you’re working in a high level language where such optimisations are pissing in the wind
And if you’re doing DSP shit in 2026, let me talk to you about the good news of zig
Most code isn’t unreadable, because it’s optimized for performance, but rather because it is needlessly complicated and should be refactored. And then reducing this complexity is likely to improve performance as well.
For example, you might draft out an algorithm with a nested loop, and then you look at it once more and realize that it can be done with a single loop. That’s very likely easier to grasp and massively better for performance, too.
If you do need to make code unreadable for performance reasons, then absolutely do make use of comments. Although I would still recommend making it understandable without resorting to comments, if possible.
Function, variable and test names can help to explain a lot. Error and log messages can be used to write out really clearly what is happening. And they have the huge advantage compared to code comments, that they show up in at least two places, which makes them more likely to be read and updated.
As someone else already wrote, the why should still be explained with a code comment. It rarely makes sense to explain implementation details in log statements…
First of all, most of the cost of a system comes from maintenance after implementation. So the idea that “an engineer can read it 40% faster” isn’t as trivial as you make it sound.
Secondly, well laid out code that doesn’t need to be commented is generally simpler to write, easier to test and easier for the original developer to conceptualize when he’s writing it. I’ve seen lots of programmers get lost in the complexities of their own approach because they don’t organize their code properly.
Finally, my understanding is that modern compilers optimize lots of things automatically, probably better than an engineer would and on all of the code. Write your code for the human to read it, let the compiler do its thing, and optimize by hand only that tiny percentage of code that causes performance issues.
To my understanding comments are ignored by compliers and runtimes having them makes no difference when the code is actually running. I may be wrong on this point though.
I was referring to this line
Code that is written for human readability omits an amount of optimisations languages have in compilers, jits, and runtimes. As code is read by machines several orders of magnitude more then a human, why make the code 20 to 30% slower for a computer to read just so an engineer can read it 40% faster?
With that being said, not all code needs to be optimised that hard. There are times where you don’t need that 20 to 30% increase in application runtime and writing code that is readable or “self documenting” works well enough.
We’re kinda breaking from the shitposting theme here, but this is good discussion
Honestly unless you’re writing DSP or 3D engine code, micro-optimisations are an absolute waste of time. Either you’re working in a low enough level language that the compiler is going to do a better job than you anyway or you’re working in a high level language where such optimisations are pissing in the wind
And if you’re doing DSP shit in 2026, let me talk to you about the good news of zig
Most code isn’t unreadable, because it’s optimized for performance, but rather because it is needlessly complicated and should be refactored. And then reducing this complexity is likely to improve performance as well.
For example, you might draft out an algorithm with a nested loop, and then you look at it once more and realize that it can be done with a single loop. That’s very likely easier to grasp and massively better for performance, too.
If you do need to make code unreadable for performance reasons, then absolutely do make use of comments. Although I would still recommend making it understandable without resorting to comments, if possible.
Function, variable and test names can help to explain a lot. Error and log messages can be used to write out really clearly what is happening. And they have the huge advantage compared to code comments, that they show up in at least two places, which makes them more likely to be read and updated.
As someone else already wrote, the why should still be explained with a code comment. It rarely makes sense to explain implementation details in log statements…
Oh thanks I see it now
First of all, most of the cost of a system comes from maintenance after implementation. So the idea that “an engineer can read it 40% faster” isn’t as trivial as you make it sound.
Secondly, well laid out code that doesn’t need to be commented is generally simpler to write, easier to test and easier for the original developer to conceptualize when he’s writing it. I’ve seen lots of programmers get lost in the complexities of their own approach because they don’t organize their code properly.
Finally, my understanding is that modern compilers optimize lots of things automatically, probably better than an engineer would and on all of the code. Write your code for the human to read it, let the compiler do its thing, and optimize by hand only that tiny percentage of code that causes performance issues.