But you should also comment it, things obvious to you aren't obvious to even future you.
General rule of thumb: Comments say why is it here, not what it does. Code itself should describe what it does.
But then you write code in the real world and find out that you have to write some ass backwards code every other day because of deadlines, backwards compatibility or whatever, and suddenly you realize that despite your best efforts, code cannot always be self documenting.
Source: me.
should
In a vacuum, sure. On a real project of substantial size with more than one programmer, I'm afraid it quickly becomes a "cannot"
Code should be self documenting.
But you should also comment it, things obvious to you aren't obvious to even future you.
General rule of thumb: Comments say why is it here, not what it does. Code itself should describe what it does.
But then you write code in the real world and find out that you have to write some ass backwards code every other day because of deadlines, backwards compatibility or whatever, and suddenly you realize that despite your best efforts, code cannot always be self documenting.
Source: me.
In a vacuum, sure. On a real project of substantial size with more than one programmer, I'm afraid it quickly becomes a "cannot"