Comments on: Why Comments Are Stupid, a Real Example

By: The Technical Debt Death Spiral - Translation Data

The Technical Debt Death Spiral - Translation Data — Sun, 16 Oct 2016 17:57:30 +0000

[…] that I added. I adopted this style of formatting after reading an article by John Sonmez called Why Comments Are Stupid. I have mentioned this article many time but it is one that can really help improve the structure […]

By: Zangdaarr

Zangdaarr — Tue, 06 Sep 2016 15:01:00 +0000

In reply to Brian Davis. If the class name can't tell what it is doing just rename it.

By: dogu

dogu — Mon, 05 Sep 2016 21:41:00 +0000

I agree with you John
In my opinion comments just look like trash and do not serve any purpose when you can just write good named code

By: A Tiny 8086 Assembler - Translation Data

A Tiny 8086 Assembler - Translation Data — Fri, 19 Aug 2016 22:42:50 +0000

[…] Overall the program, is not bad because the functions are relatively short but oh those comments! I have pretty much terminated the use of comments in my code. Morphing the comments into function names makes the program much easier to understand. The comments do not become stale because they do not exist. You can find an example of how to do this at Why Comments are Stupid. […]

By: Zangdaarr

Zangdaarr — Tue, 09 Aug 2016 12:43:00 +0000

This refactor is definitely easier to read and understand than the commented code. It is clean and adhere to the SRP.

However, I would not have done it this way since, as a rule of thumb, I do not declare class members for things that have no other purpose out of their method. This can lead to maintenance issues (particularly with the setters that were introduced). So I would just have kept this variables local.

The point to demonstrate however, is clear. More often than not, I got file where comments actually prevents me to read the code because they are a constant source of interruption. Comment are like keywords using them too much mask the moment they serve an actual purpose and can’t be avoided.

This is the case for 99.9% of them. If you think you can’t avoid your comment, start by rewriting your code.

By: Refactoring: Extract a Method, When It’s Meaningful

Refactoring: Extract a Method, When It’s Meaningful — Tue, 26 Apr 2016 10:41:48 +0000

[…] Christin Gorman argued that this technique sounds like a no-brainer. For addition, there was a blog post by John Sonmez about refactoring of a .NET BCL-method using this technique (though the original intention was to […]

By: Refactoring: Extract a Method, When It’s Meaningful – .NET, WPF, XAML, UWP, C#, CSharp, Universal Windows Platform

Mon, 25 Apr 2016 13:54:33 +0000

By: Randy

Randy — Mon, 07 Dec 2015 03:45:00 +0000

I know this is somewhat an old post, but i’m still fairly new to programming so I’m still learning and trying to figure out good practices. I always thought refactoring code was in other words reducing the code, without changing what it does. In your example you’ve almost doubled the file size just to remove 4 comments, is it really worth the trouble changing code to remove comments if it means adding to the filesize? Everything seems to be about reducing the file size if at all possible, I mean thats why we now how minified versions of files for production no? That was just a snippet of code…If there were 100 comments in a piece of code with the example I just assume the file size would be a lot bigger and the whole process would just be pointless.

By: Tracker1

Tracker1 — Sat, 07 Nov 2015 17:08:00 +0000

In reply to Matt B.

Usually that reason is terseness, brevity, or otherwise more efficient code… For example, in js is common to rely on Boolean expression shorting, which can mean terse code… It’s usually better in terms of size and personal performance, but should often also include a comment of intent.

A single expression that shorts is simpler than multiple conditional checks and expressions… Or could be. Sometimes you expect people to have some minimal understanding.

By: Tracker1

Tracker1 — Sat, 07 Nov 2015 17:00:00 +0000

In this case, I would suggest you’ve created unnecessary overhead for execution of a fairly low level piece of code likely to be used frequently… While I understand the intent, breaking into meaningful functions or establishing named lambdas would be less overhead. Though lambda closures in .Net likely isn’t much better than a class instantiation.

Idempotent functions are easy to test while classes are subject to mutability and variance. Though oo vs fp is it’s own debate that I’m not trying to start, I think what you’ve created is more risky in use than the original code.

I agree though that clear intent through naming is often better in maintainable code than comments.