One of the recent trend is to minimize quantity of comments inline in code files and improve quality of comments. This caught up like fire and moving towards the danger zone of no comment-era. This is all good provided the code is written with maintenance in mind and not for short term goals of long running product to satisfy some OKR set by somebody higher up or to meet some dead line which coincidently aligns with your performance review period 🙂
I am all for those learning of clean code. Good variable names, smaller classes, smaller methods, meaningful names to methods, highly readable code, lesser number of lines of code, let the compiler worry about optimizing my code etc…
But this comments is a tricky thing. when the code is written first time a lot of thought goes into it. compromises will be made, hard decisions will be made. Developers are moving intra-companies, inter-companies like crazy Salagars. All this context is lost for future developers. Now they are told more comments is bad pattern.
One natural place for all this information is code review description, self-comments, discussions. It is already happening there – just that this information is not easily available to future developers readily.
If Git(hub) can find a way to make this information available to editors (e.g.. VSCode, which already shows lot of Git history while you try to edit a code-file) it will be pretty useful to developers who are trying to fix that nagging bug and keep swearing “who the fuck wrote this shit and why?”