Self-taught designer, developer, and musician. JS, CSS, React, Next, Vue, Node, and much more. Studying computer information systems at Mississippi College.
One thing I disagree with: Avoid Comments. Comments are in the spec for a reason, and there's no reason NOT to use them. Yes, code should be relatively readable without them, and yes they should be removed in production, but commenting code is a very important practice that drastically aids collaboration efforts.
Agreed. You should include the "why" in your comments. Not the "what". Code itself should be enough to tell "what" it does, but sometimes it is a struggle to guess why (undocumented business requirements or a bug in IE11, etc)
Robert C. Martin argues against this is book. If you have to write comments in order to explain your code, it is most likely that the code you wrote is already bad and has code smells. Code should describe comments rather than the other way around.
Although this doesn't mean you should avoid comments. Writing good comments is something anyone would recommend. For instance, documenting your code as in JSDocs or PHPDocs. You can use it to write "TODOs." Generally, low level operations should be abstracted away. You could comment the low level abstractions if it is complex but yeah.
There are no hard and fast rules. If you give your code to me and I understand it quickly (clean code) and can make modification in it without breaking anything (loosely coupled) then that's great!
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.
One thing I disagree with: Avoid Comments. Comments are in the spec for a reason, and there's no reason NOT to use them. Yes, code should be relatively readable without them, and yes they should be removed in production, but commenting code is a very important practice that drastically aids collaboration efforts.
Agreed. You should include the "why" in your comments. Not the "what". Code itself should be enough to tell "what" it does, but sometimes it is a struggle to guess why (undocumented business requirements or a bug in IE11, etc)
Robert C. Martin argues against this is book. If you have to write comments in order to explain your code, it is most likely that the code you wrote is already bad and has code smells. Code should describe comments rather than the other way around.
Although this doesn't mean you should avoid comments. Writing good comments is something anyone would recommend. For instance, documenting your code as in JSDocs or PHPDocs. You can use it to write "TODOs." Generally, low level operations should be abstracted away. You could comment the low level abstractions if it is complex but yeah.
There are no hard and fast rules. If you give your code to me and I understand it quickly (clean code) and can make modification in it without breaking anything (loosely coupled) then that's great!