For the comments tip you gave, I have to say that we in our team allow comments. But they should not explain what is done at a specific code block but explain WHY it was done that way. Maybe it's a little hacky solution but necessary because of dependencies. Therefor other developer should not waste time on trying to refactor some code only to realise that this code is "the currently best option"
But: Nice post! I'm happy that we do the most of those patterns and tips ourself already :)
I have 3+ years of experience in Product Engineering. The challenges of scaling and improving UI is my motivation for learning new things. I’m dedicated to focus on UX and writing clean, modular code.
Absolutely correct. 100% Agree with you. Comments are not a bad practice at all, but enforcing comments above every single function, variable declaration leads to bad code. We are also following comments for a business logic explanation so that other engineers can quickly get the context and understand the use case.
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.
For the comments tip you gave, I have to say that we in our team allow comments. But they should not explain what is done at a specific code block but explain WHY it was done that way. Maybe it's a little hacky solution but necessary because of dependencies. Therefor other developer should not waste time on trying to refactor some code only to realise that this code is "the currently best option"
But: Nice post! I'm happy that we do the most of those patterns and tips ourself already :)
Absolutely correct. 100% Agree with you. Comments are not a bad practice at all, but enforcing comments above every single function, variable declaration leads to bad code. We are also following comments for a business logic explanation so that other engineers can quickly get the context and understand the use case.