markdown guide
 
 

I agree, but it depends on the language. In a strongly typed language that is usually the case but when you don't even know what is the type of data that the function returns then you might need some comments.

 

That's why you shouldn't have arbitrary variable names (-> good code)...

Imagine the following (pseudo-)Common Lisp code:

(let ((username (get-username-from-database)))
    ;; 35734 lines of other code...
    (do-something-with username))

Chances are that username will be a string - which is obvious even 35734 lines later. When in doubt, you might even prefix it like you would do in strongly typed languages:

int iNumber = 0;
std::string strNumber = "0";

Admittedly, <type>Number is a horrible name for a variable. ;-)

I fully agree

The problem is that there are times we don't create good code, we create bad code in a hurry and comment it (instead of refactoring it) due to time constraints. Couple that with working in a team of developers and comments become the norm. Unfortunately, we can't base our assumptions that the whole team will make good code and not create ambiguity with their naming.

If you don't work in a team, then by all means, don't use comments, that's what I usually do 99% of the time in my personal side projects.

Believe me, I wish we could simply get away from comments altogether since they:

  • Aren't linked to what the code actually does (changing code doesn't change the comment and vice-versa)
  • Are mostly boilerplate and sometimes add tons of unnecessary lines in our code.

Unfortunately, we can't base our assumptions that the whole team will make good code and not create ambiguity with their naming.

It is everyone's responsibility to make a better team. :-)

If you don't work in a team, then by all means, don't use comments, that's what I usually do 99% of the time in my personal side projects.

Ha! Without any comments, I would not understand some of my code after a few months ... but I'm working on it!

 
Classic DEV Post from May 2

The Art of Programming

One of the most consolidated misconceptions about programming, since the early days, is the idea that such activity is purely technical, completely exact in nature, like Math and Physics. Computation is exact, but programming is not.

Sergiu Mureşan profile image
Thank you for stopping by! I am a full-stack developer that combines the power of entrepreneurship and programming to make the lives of programmers easier.