I've recently watched "Clean Code - Uncle Bob" (Lesson 1 and 2, both on YouTube). His conclusion is that whenever any line of code requires comments, it's a failure on the developers part because good code should contain variable and function names that explain themselves, thus making comments unnecessary (though I disagree on the comment part, because there are some good reasons for comments in code). He mentions that a lot of developers dislike longer names because it makes the code look "uncool", bigger in file size, looks bloated, leads to horizontal scrollbars in the IDE (or wraps it to a new line) and some developers are even under the false impression that longer names lead to slower code. Just like in your article, he mentions to use names that are perfectly understandable even if consist of multiple words. We really need to stop being afraid of using longer names and start using names so that the name itself becomes self-explanatory and can potentially work without any additional commentary. Thanks again for the article.
Thanks for the feedback, I'm glad you appreciated it. I agree with Robert Martin on his points about code communicating intent as much as possible. I wish he focused more on the people behind the code and expressing kindness to each other being as important as getting the code right.
Regarding comments, I personally try to add comments for context that is important and isn't really part of the code - e.g. intended lifespan of the code, maybe even linking to a ticket with an important conversation. For communicating intent - I try to resort to tests as much as possible since they're more inclined to change with the code. I don't consider it a failure to add a comment because it was hubris for me to ever think I didn't need them. I think it's an achievement of self awareness to know where to add proper comments rather than a failure of coding ability.
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.
Great article, thank you.
I've recently watched "Clean Code - Uncle Bob" (Lesson 1 and 2, both on YouTube). His conclusion is that whenever any line of code requires comments, it's a failure on the developers part because good code should contain variable and function names that explain themselves, thus making comments unnecessary (though I disagree on the comment part, because there are some good reasons for comments in code). He mentions that a lot of developers dislike longer names because it makes the code look "uncool", bigger in file size, looks bloated, leads to horizontal scrollbars in the IDE (or wraps it to a new line) and some developers are even under the false impression that longer names lead to slower code. Just like in your article, he mentions to use names that are perfectly understandable even if consist of multiple words. We really need to stop being afraid of using longer names and start using names so that the name itself becomes self-explanatory and can potentially work without any additional commentary. Thanks again for the article.
Thanks for the feedback, I'm glad you appreciated it. I agree with Robert Martin on his points about code communicating intent as much as possible. I wish he focused more on the people behind the code and expressing kindness to each other being as important as getting the code right.
Regarding comments, I personally try to add comments for context that is important and isn't really part of the code - e.g. intended lifespan of the code, maybe even linking to a ticket with an important conversation. For communicating intent - I try to resort to tests as much as possible since they're more inclined to change with the code. I don't consider it a failure to add a comment because it was hubris for me to ever think I didn't need them. I think it's an achievement of self awareness to know where to add proper comments rather than a failure of coding ability.