Writing comments*. Just stop doing it.

Clean Code rules!

Why would you even say that?

@hubiruchi there is an argument that goes along the lines of "if you need to write comments, your code isn't clean enough.". There's something to be said for this, especially since code never lies, where comments can easily get stale.

This exactly, I had an assignment on school where you would get more points for being one of those people that comments every line of code

Clean code doesnt mean never write comments. Just try to make your code self documenting as much as possible and only add comments where absolutely necessary. Also if you write comments focus on the why and not the what part

If you think your code is better then your words then probably:
0) you dont really know how to express yourself in comments
1) you never had to hear from someone reading maintaining your code "why the fuck did he made this like that".

Even if your code is clean your motives cannot be read from the code. Write comments to help anybody not read your code to use it, and understand what you want to say

@hubiruchi when you write clean code, your code speaks for you.

Instead of comments you just need to name correctly your methods.

If your methods do more than one thing, divide them to more.

If you have many methods, create a separate module (project) and a reference to it.

The trick for clean code is to write it FIRST to implement clean code. It seems too forced and tiring to change a project to implement clean code principles than to maintain it. But if you have an already clean code program, to test and maintain it is not an additional task. It's just the last necessary part of yhe coding and it is fairly easy to do.

I speak from experience

For those ranting about how amazing comments are I will reply once for all of you. Comments can lie. Code will always tell the truth. There is a reason why you rarely if ever see comments on open source repos of big companies. Because big self descriptive names are your comments. Method summaries are bad as well but those are necessary some times in library projects mostly. Todos are also fine as long you actually go back to them eventually.

@hubiruchi you are wrong in so many levels, probably because you’ve never been exposed to good clean code. The argument, with the exceptions I said above, isn’t really disputable. In enterprise interviews you will lose the job if you do something like that.

@Elfocrash @lostinmyworld you say good things. Clean code is important. But if you think that everybody can automatically understand what you want to do with your code just from reading it and that your naming will mean the same thing for everyone then you are a FUCKING EGOCENTRIC PERSON WHO LEAVE EVERYBODY AFTER YOU TO WONDER "WTF THIS SHIT DO"

Also, you dont even want anyone to read your code, but you do want anyone to read your documentation

@hubiruchi the last bit made no sense mate. What does documentation have to do with comments in code? One doesn’t replace or negate the other. Don’t shoot the messenger. These are not my words. They come from people with way more experience and the scar tissue to show.

It’s simple as that.
- Can I write false comments to confuse you?
- Ofc I can.
- Can I do that with code?
- Nop

Check mate mate

@Elfocrash The problem with saying clean code is enough is that "clean" is subjective. Also, code cant explain meaning.

@hubiruchi the documentation does describe WHAT your code do, as in "what this library implements" but clean code principles describe HOW your code implements it.

In comments you can write something like "this method checks for errors" and your method may does that but by many months of maintaining your code (and not only by you) this method may does more things that are not described in comments or less things that are included in the first comments.

You can not be sure. In enterprise level (many developers, many testers, many projects) writing comments inside your code may become more disorienting than helpful.

Clean code principles on the other hand can be checked if implemented by automatic tools and so it's easy to say "this method is not clean code" or by a moment's look at your code. It's pretty easy to check and what it implements is basic this: "you don't have to trust my words. My implementation is speaking by itself"

@hubiruchi I genuinely feel sorry for you, mainly because you remind me of myself. I wanna sit down and pair program with you.