i am fed up with this code, when will people learn to add comments on code👿👿

In our team we have a rule to never write comments

@danielspaniol mate your teams a shit!☺

It is great. The reasoning behind is the idea that your code is shit if you need comments

@danielspaniol that's an intriguing concept but using comments to at least segment sections of code is useful to quickly find a section that is doing something.

Comments should explain why, not what. If you need comments to explain what your code is doing, clean your code up until those comments become unnecessary.

The only people who tend to look at code are people who should understand your code, but not necessarily the reason behind it.

Well commented code is shitty code that need excuses.

Code should tell what it does, not how.
If your code is telling "how" and not "what" you should refactor it.

@nocgod I know for maintaining code it's infinitely cheaper to the business to document. The two aren't mutually exclusive. You can have good code and document.

@ninjatini documentation as in javadoc style is great for future reference and maintenance, and for every bug fixed - unit+functional+integ/e2e tests added. Of course code should be thoroughly tested with meaningful e2e tests that describe the system use case flow.

Comments inside the code should be rare and sparse since no one will maintain a god damn comment.

a broken test === broken build === red in the CI === notifications in NATO distribution === developer fixes the code or adjusts the test to systems flows.

Only shit code needs comments, so instead of bitch in about the lack of comments, maybe bitch about the extensive shit code and lack of unit tests.

@nocgod As with anything it depends. In our environment I'm glad people document when they do because we are extending closed source compiled code and it would take way too long to decompile everything every time I want to call a method or instantiate a class. Our vendor has a lot of logic tucked into those classes so it's nice to have.

@ninjatini documentation !== Commenting the code.

Leaving documentation of what a method expects, what it returns and what it does is great, especially for external interfaces. BTW a method, interface should never do more than it's name suggests and never should do more than one thing. Understanding what a method does solely out of documentation and not the name+prameters+response is a red flag for a code smell.

Commenting an if statement is wrong because it means the logic of this if statement is too complicated to understand from reading the code, hence the comment is an excuse for writing poor code.

@nocgod It still all really depends. Our transactions are financial in nature and while it's not rocket science to read through scripts and sprocs, it would take a damn long time. So I'm glad people comment in there as well. I just want broad strokes of what the next few hundred lines are doing or if there is any weird logic that is included. Scripts have a tendancy to do something simple but still take thousands of lines. We're a non profit as well so there is a shit ton of legalities and rules you have to follow. Like I said, not rocket science but the scripts get long quickly.

@ninjatini i agree with you!