,
12 tweets,
3 min read
Read on Twitter
One way or another ever since we started writing code, some rules have been imposed on us.
Whether that's "indent your code properly", or "name your variables correctly", these rules changed the mindset of today's developers away from the "write - compile - done" flow.
The one rule that has stuck with us and the first thing that usually comes to mind when we think of "good code", is "ALWAYS LEAVE COMMENTS". "Comments help other developers know what your function does".
This is mostly taught to future developers at school or at university, where teachers would deduct points from your homework if you don't leave comments on your code.
This mindset has stuck with the vast majority of developers who still consider leaving comments as best practice.
This thought process though is being challenged by books like @unclebobmartin 's "Clean code":
"Comments are a failure". "Comments Do Not Make Up for Bad Code". "Focus on good self-explanatory code instead of comments"
Personally I think this is a much better way of doing things and a better rule to follow if you want your code to be efficient, clean and well-maintained
The problem lies when the developers that have been taught to "leave comments or else..." are advised to focus on good code instead.
Their reaction is similar to telling a grown man to change how they walk or change how they breathe. They've been doing it a certain way their whole lives, and they're not willing to change.
I guess the only way to convince them to change their processes is to show them how better it is to have good code instead of good comments, how fast their workflow will become and why unnecessary comments are - in @KentBeck's words - "code smells"
