First please don't promote wrong things!
I honestly didnt know where to start arguing so i won't and I will give you another perspective.
Being in a real world project with multiple teams or devs working on it is complex enough. If for whatever function or line you need to comment might as well change jobs. This is not scalable at all. We have all sorts of tools at are disposal. Typescript, unit tests, automation tests, documentation of features (not blocks of code) function complexity tools.
Commenting means one of the two things when code isn't self explanatory that you are doing too many things or you aren't giving correct variable, class, function names so things needs to be explained. Again this isn't ok. This needs to be corrected. Leaving a comment will solve the situation at that moment. What about when someone refactors that piece of code. The chances of the comments being updated accordingly are slim to none
When you read code you need to understand it. Having comments negates the purpose of readable code and allows windows of badly written code because "well it was difficult so i have added a comment". but then another dev comes to enhance the functionality and will either read the comment and understand nothing because most likely it's an essay which makes no sense so he starts reading the code and again makes no sense of it so he starts debugging line by line till he understands it. If you can write good comments and bad code then ask someone to help you write in a way that's readable. If your content is short and still have to write it, seriously look at your code and find out why you need to comment it. Something so wrong. Sit and think plan or what you want. Finally and most importantly unit tests are your documentation of your class or module. If you don't understand the code in place read the unit tests which should have good description of functionality not a comment which will be deprecated in the first iteration.
Don't use comments as an excuse to write tens or even hundreds of lines code cause the only thing that you are adding to is complexity for the next developer to have to read through and try and change which will most likely lead to a refactoring.
If what whatever reason you meant documentation in your topic this is completely different and i couldn't agree more with you but i don't think you do.
Please don't promote bad practices cause if others adopt what you suggest repos will double in size :p
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First please don't promote wrong things!
I honestly didnt know where to start arguing so i won't and I will give you another perspective.
Being in a real world project with multiple teams or devs working on it is complex enough. If for whatever function or line you need to comment might as well change jobs. This is not scalable at all. We have all sorts of tools at are disposal. Typescript, unit tests, automation tests, documentation of features (not blocks of code) function complexity tools.
Commenting means one of the two things when code isn't self explanatory that you are doing too many things or you aren't giving correct variable, class, function names so things needs to be explained. Again this isn't ok. This needs to be corrected. Leaving a comment will solve the situation at that moment. What about when someone refactors that piece of code. The chances of the comments being updated accordingly are slim to none
When you read code you need to understand it. Having comments negates the purpose of readable code and allows windows of badly written code because "well it was difficult so i have added a comment". but then another dev comes to enhance the functionality and will either read the comment and understand nothing because most likely it's an essay which makes no sense so he starts reading the code and again makes no sense of it so he starts debugging line by line till he understands it. If you can write good comments and bad code then ask someone to help you write in a way that's readable. If your content is short and still have to write it, seriously look at your code and find out why you need to comment it. Something so wrong. Sit and think plan or what you want. Finally and most importantly unit tests are your documentation of your class or module. If you don't understand the code in place read the unit tests which should have good description of functionality not a comment which will be deprecated in the first iteration.
Don't use comments as an excuse to write tens or even hundreds of lines code cause the only thing that you are adding to is complexity for the next developer to have to read through and try and change which will most likely lead to a refactoring.
If what whatever reason you meant documentation in your topic this is completely different and i couldn't agree more with you but i don't think you do.
Please don't promote bad practices cause if others adopt what you suggest repos will double in size :p