To comment or not to comment?

I find that comments are more useful for explaining why rather than how or what. Your code should be readable enough for people to know what it’s doing, but sometimes the reason isn’t obvious.

Like if you’re working around a limitation of a library you’re using. Or you’re working around some old code (technical debt) that you can’t refactor now. Yes I know ideally you’ll immediately fix all the problems in a codebase instead of working around them, but that’s not always realistic. So sometimes you need comments to make the code make sense.

Write as few comments as possible. The code should be readable on its own. Use good symbol names and structures.

Reserve comments for things that are not expressed in code well, and keep them minimal. Unlike code, there is nothing checking that comments are correct, thus tend to get stale. Thus focus on information that won't likely get stale.

I think comments are essential for code snippets that were hard fought. If it took you considerable time to design and implement, its worth explaining what is happening there.

Strong naming conventions and clear delineation of logic does not act as a substitute for a quick roll up explanation.

Future you, or anyone else, shouldn’t need to read the entire function (and any other abstractions) to know what the code is doing and controlling.

I personally encourage my colleagues to write as few as possible comments. I call such comments 'excuses'.

When I read a function or method signature it should be immediately clear to me what that function or method does, how it should be use and what's its purpose. I shouldn't have to know any details about the implementation to use it. Virtually any function can be designed with such clarity in mind.

A similar approach can be attempted for implementation. Any code contained in a function 'worthy' of an 'excuse' can be refactored into another function with clear intent and purpose. I don't care that it will be called in a single place if it brings clarity.

Of course, I allow 'excuses' if the offending piece of code is not the developer's fault, like with strange business logic or partial solutions based on incomplete information. My point is that comments shouldn't be used liberally. Code can and should be written with clarity in mind, especially if you share the codebase with lots of other devs.

I love function name / variable name like a comment,

It can easily to read like a flowchart,
And comments

public static Coffee CreateCoffee(
CoffeeTypeEnum coffeeType)
{
    var coffee = new Coffee();
    var shouldAddMilk = IsNeedMilk(coffeeType);

    if (shouldAddMilk)
    {
        coffee.Add(Milk);
    }

    coffee.Add(Espresso);

    return coffee;
}

But if you have any technical issue / temporary fix / some business walk around
It should be write a command, create some tickets and fix it

private bool IsNeedMilk(CoffeeTypeEnum coffeeType)
{
    // FIXME #123 MilkFoam shouldn't is a type of Coffee
    if (coffeeType == CoffeeTypeEnum.MilkFoam)
    {
        return true;
    }

    var result = MilkCoffeeTypes.Contains(coffeeType);
    return result;
}

I write docstrings.

I learned to use docstrings in python and naturally use them because I work mostly in python currently. But if I reverted back to C++ or another language that has no built in support for docstrings, I would still try to write "comments" formatted like a docstring. A docstring is a bit of definitive and explanatory text that accompanies the declaration of a function or other object. Quoting python standard PEP-257:

The docstring for a function or method should summarize its behavior and document its arguments, return value(s), side effects, exceptions raised, and restrictions on when it can be called (all if applicable). Optional arguments should be indicated. It should be documented whether keyword arguments are part of the interface.

The docstring for a class should summarize its behavior and list the public methods and instance variables. If the class is intended to be subclassed, and has an additional interface for subclasses, this interface should be listed separately (in the docstring). The class constructor should be documented in the docstring for its init method. Individual methods should be documented by their own docstring.

Every "public" class, function, or method gets a docstring that conforms to the above.

I've heard in many places that the name and call signature of a function should be self-explanatory of how to use it, and the code should be self explanatory as to what it does. But if you think about it, this is an extremely tall order in most cases, especially when code is written under a deadline.

One of the major benefits of factoring code out into small functions (ideally without side-effects) is that the developer doesn't have to handle the cognitive load of what all of the application code does all at once. So even if code can be reasonably described as being self-explanatory, in the absence of docstrings or comments the developer still has to read and understand how the function does what it does when all they really needed was to know what it does. This is a distraction from the developer's task at hand - writing the calling function and understanding it's internal state.

Additionally, following a common format for docstrings on all functions opens the door to automating the generation of API documentation. This is particularly useful as it is much easier to ensure that documentation of the API is up to date when it is right in front of you whenever making a change to a function or method.

As far as actual non-docstring comments, I rarely write any and they usually describe the why behind something that came up in some subtle edge case, just to make sure any further modification takes note of the special problem, i.e. "# We need to detach foo before linking quux in cases of network congestion, see ticket 38745".

Ideally only the public methods should have a method comment. Private methods may have a method comment and only use inline-comments if really not understandable. All the rest is about proper naming of Classes/Methods/Properties/Variables, separations of concerns and methods as short as possible (they should do one thing only). But thats the ideal case of code...

Something that wasn't brought up here is writing comments after code has been written and in production.

I'm talking about the need to revisit code due to bugs, refactoring or when the code you're writing now needs to use it.

In these cases, when you don't immediately understand the code and need some mental gymnastics to grok it, instead of writing notes to yourself - do so in comments.

My personal recommendation is to use markdown in a code block to go through the thought process. In some cases I even added flowcharts or sequences using mermaid.js

Usually, this is also a good indication that the code needs to be refactored. Until it happens, your comments will help you or someone else who will need to revisit this code in the future.

Any hard rule about this will slip quickly from "helpful convention" to "torturous ideology".

Use comments to explain why a piece of code is doing what it's doing. Or to help organize thoughts. Or to document public methods for tooltips. And do it consistently, unless that doesn't fit, then do something else.

But heaven's sake, please do inject jokes and humor into your comments. I distrust teams that are against this.

I use comments only when working in a project that requires third party integrations, as they might not have the best clean code practices (mainly because the third party tools are outdated).
When working in projects where there is no integration or the third party software is new or easier to use, I usually don't write comments, but always create a good Readme and a Wiki with most of the business logic