Comment from my group project teammate. You don’t need to comment every line lol

  • waigl@lemmy.world
    link
    fedilink
    English
    arrow-up
    70
    ·
    edit-2
    15 days ago

    Writing good comments is an art form, and beginner programmers often struggle with it. They know comments mostly from their text books, where the comments explain what is happening to someone who doesn’t yet know programming, and nobody has told them yet that that is not at all a useful commenting style outside of education. So that’s how they use them. It usually ends up making the code harder to read, not easier.

    Later on, programmers will need to learn a few rules about comments, like:

    • Assume that whoever reads your code knows the programming language, the platform and the problem domain at least in general terms. You are not writing a teaching aid, you are writing presumably useful software.
    • Don’t comment the obvious. (Aside from documentation comments for function/method/class signatures)
    • Don’t comment what a line is doing. Instead, write your code, especially names for variables, constants, classes, functions, methods and so on, so that they produce talking code that needs no comments. Reserve the “what” style comments for where that just isn’t possible.
    • Do comment the why. Tell the reader about your intentions and about big-picture issues. If an if-statement is hard to parse, write a corresponding if clause in plain English on top of it.
    • In some cases, comment the “why not”, to keep maintenance programmers from falling in the same trap you already found.
    • smeg@feddit.uk
      link
      fedilink
      English
      arrow-up
      55
      ·
      15 days ago

      Commenting the why not is key. Half my comments are explaining why I had to use this hack as a warning that the obvious fix doesn’t work!

    • Tamkish@programming.dev
      link
      fedilink
      arrow-up
      20
      ·
      edit-2
      15 days ago

      I would argue that if an if statement is hard to parse, replace the entire condition with simpler to read (but way more specific) variables that you assign values (the original condition expression) in the line above. No need for comments in that case

    • Thorry84@feddit.nl
      link
      fedilink
      arrow-up
      13
      ·
      edit-2
      15 days ago

      Good advice, just to add to this:

      • Comments should be part of code review, having at least two pairs of eyes on comments is crucial. Something that’s obvious to one person maybe isn’t so obvious to another. Writing good comments is as hard or harder than writing good code, so having it checked for mistakes and quality is a must
      • Comments aren’t the actual documentation and aren’t a reason not to write documentation to go along with your code. Often I see larger projects where each class and function is documented in comments, but the big picture and the how and why of the overall structure is completely missing. Remember that in the real world you often have a lot of folk that need to understand how the code works, who aren’t programmers themselves. They can’t read the code or don’t have access to the code. Writing documentation is still important.
      • Please for the love of god when you change code, check if the comments need to be updated as well. Not just around the immediate area, but also the entire file/class and related files. I’ve worked on large codebases before with a high wtf factor and having the code do something different to or even opposite the comments is a nightmare. I’d rather have no comments than wrong comments.
      • FlorianSimon@sh.itjust.works
        link
        fedilink
        arrow-up
        8
        ·
        15 days ago

        This is a notoriously bad book. If you read the part about comments (which I don’t know about, and am willing to accept is good) make sure to skip everything else because Robert Martin is a fraud.

      • magic_lobster_party@kbin.run
        link
        fedilink
        arrow-up
        7
        ·
        15 days ago

        I’d rather have no comments than wrong comments.

        I’ve seen cases of outdated comments in the same line of code it’s describing. People suck at maintaining comments.

    • Incandemon@lemmy.ca
      link
      fedilink
      arrow-up
      11
      ·
      15 days ago

      Don’t comment what a line is doing. Instead, write your code, especially names for variables, constants, classes, functions, methods and so on, so that they produce talking code that needs no comments.

      Over and over and over again in my experience this just doesn’t work. Readable code does not substitute for comments about what the code should be doing.

    • magic_lobster_party@kbin.run
      link
      fedilink
      arrow-up
      2
      arrow-down
      4
      ·
      15 days ago

      Do comment the why

      In this day and age of source control I don’t think this is fully necessary. If you want to know the why, you can look into the commit history and see which ticket is connected to it. There you might even see the discussions around the ticket as well. But this requires good source control discipline.

      It has helped me many times.

      • floofloof@lemmy.ca
        link
        fedilink
        English
        arrow-up
        11
        arrow-down
        1
        ·
        edit-2
        15 days ago

        Why not put the “why” in a comment and save people the job of dredging through old commits and tickets to figure out what the code is for? I’d thank someone for saving me the hassle.

        • ExperiencedWinter@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          13 days ago

          In any modern IDE “dredging through old commits” means clicking a single button to see who last changed the line. From there it often makes sense to go look at the PR to see a higher level of what was changed. You cannot include all of that context in a single comment.

        • magic_lobster_party@kbin.run
          link
          fedilink
          arrow-up
          2
          arrow-down
          2
          ·
          15 days ago

          You can also do that if you think it’s useful.

          Going back to the original ticket can offer far more info than what any “why” comment can give. You can see how old it is, if there are any connected tickets, who were involved with it, step by step instructions how to reproduce the bug, etc.

  • Cratermaker@discuss.tchncs.de
    link
    fedilink
    arrow-up
    64
    ·
    16 days ago

    Software devs in general seem to have a hard time with balance. No comments or too many comments. Not enough abstraction or too much, overly rigid or loose coding standards, overoptimizing or underoptimizing. To be fair it is difficult to get there.

    • Doc Avid Mornington@midwest.social
      link
      fedilink
      English
      arrow-up
      51
      ·
      16 days ago

      It’s better to have useful comments. Long odds are that somebody who writes comments like this absolutely isn’t writing useful comments as well - in fact, I’m pretty sure I’ve never seen it happen. Comments like this increase cognitive overhead when reading code. Sure, I’d be happy to accept ten BS useless comments in exchange for also getting one good one, but that’s not the tradeoff in reality - it’s always six hundred garbage lines of comment in exchange for nothing at all. This kind of commenting usually isn’t the dev’s fault, though - somebody has told a junior dev that they need to comment thoroughly, without any real guidelines, and they’re just trying not to get fired or whatever.

    • henrikx@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      29
      ·
      edit-2
      16 days ago

      Universities often teach students to write a lot of comments, because you are required to learn and demonstrate your ability to translate between code and natural language. But this is one of the things that are different in professional environments.

      Every comment is a line to maintain in addition to the code it describes. And comments like this provide very little (if any) extra information that is not already available from reading the code. It is not uncommon for someone to alter the code that the comment is supposed to describe without changing the comment, resulting in comments that lie about what the code does, forcing you to read the code anyway.

      It’s like if you were bilingual, you don’t write every sentence in both languages, because that is twice as much text to maintain (and read).

      The exception of course, being if you are actually adding information that is not available in the code itself, such as why you did something a particular way.

      • Nevoic
        link
        fedilink
        arrow-up
        15
        ·
        16 days ago

        Yup this is the real world take IME. Code should be self documenting, really the only exception ever is “why” because code explains how, as you said.

        Now there are sometimes less-than-ideal environments. Like at my last job we were doing Scala development, and that language is expressive enough to allow you to truly have self-documenting code. Python cannot match this, and so you need comments at times (in earlier versions of Python type annotations were specially formatted literal comments, now they’re glorified comments because they look like real annotations but actually do nothing).

        • smeg@feddit.uk
          link
          fedilink
          English
          arrow-up
          3
          ·
          15 days ago

          Exactly! Write your code to be as clear and self-descriptive as possible, and then add a comment if something is still not immediately obvious.

          • Starbuck@lemmy.world
            link
            fedilink
            arrow-up
            5
            ·
            15 days ago

            If I see comments explaining every other line, especially describing “what” instead of “why”, I assume the code was written by a recent grad and is going to be bad. Describing what you are doing looks like you are doing a homework assignment.

            Like on that line, obviously we’re initializing a variable, but why 1 instead of 0? Could be relevant to a loop somewhere else, but I guess I’ll have to figure that out by reading the code anyways.

      • magic_lobster_party@kbin.run
        link
        fedilink
        arrow-up
        3
        ·
        15 days ago

        It’s like if you were bilingual, you don’t write every sentence in both languages, because that is twice as much text to maintain (and read).

        This is a very good analogy. And just like with natural languages, you might have an easier time expressing an idea in one language but not the other. Comments should provide information that you find difficult to express with code.

    • cheddar@programming.dev
      link
      fedilink
      arrow-up
      5
      ·
      edit-2
      16 days ago

      If there are too many comments, it means you have to support them just like the code itself. Otherwise, like any other documentation, comments will quickly go out of sync.

    • Darohan@lemmy.zip
      link
      fedilink
      arrow-up
      7
      arrow-down
      6
      ·
      16 days ago

      Legit, I’ll take this over the undocumented spaghetti I too often see written by “professionals”.

      • Fal@yiffit.net
        link
        fedilink
        English
        arrow-up
        11
        ·
        16 days ago

        This is so wrong. I would absolutely prefer no comments over incorrect comments, which is exactly what happens when things get over commented

  • fibojoly@sh.itjust.works
    link
    fedilink
    arrow-up
    16
    ·
    15 days ago

    More useful would be what sort of values is acceptable there. Can I use team number 2318008? Can I use team 0? If not, why not? WHY / WHY NOT is often useful.

  • u/lukmly013 💾 (lemmy.sdf.org)@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    17
    arrow-down
    2
    ·
    16 days ago

    I am not a programmer, I just barely wrote one bash script in the past. But I’d say more comments are better than too few.

    When I later wanted to edit it, I got completely lost. I wrote it with absolutely no comments.

    • riodoro1@lemmy.world
      link
      fedilink
      arrow-up
      22
      arrow-down
      1
      ·
      16 days ago

      Bash is a shit „language” and everytime i need to write the simplest thing in it I forget which variable expansion I should use and how many spaces are the right amount of spaces. It’s impossible to write nice to read bash, but even in C you can write code that comments itself.

    • floofloof@lemmy.ca
      link
      fedilink
      English
      arrow-up
      3
      ·
      15 days ago

      I’ve been programming for almost 25 years and I’d still rather see too many comments than too few. A dogmatic obsession with avoiding comments screams “noob” just as much as crummy “add 1 to x” comments. If something is complex or non-obvious I want a note explaining why it’s there and what it’s supposed to do. This can make all the difference when you’re reviewing code that doesn’t actually do what the comment says it should.

    • Fades@lemmy.world
      link
      fedilink
      arrow-up
      5
      arrow-down
      4
      ·
      edit-2
      15 days ago

      Wrong. Too many comments makes the code messy and less readable and also it provides ZERO value. Just look at the post, WHAT is useful about ANY of that comment???

      All it is is a waste of goddamn space, literal junk crowding the actual code.

      I love how you admit you aren’t a developer but feel quite confident to tell us that a larger number of comments automatically means it’s better.

      This person articulated it better than I: https://midwest.social/comment/10319821

      • LwL@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        15 days ago

        Too many is still better than too few, and it’s not close. Useless comments make parsing a bit harder. Missing comments can mean hours of research.

        • sping@lemmy.sdf.org
          link
          fedilink
          English
          arrow-up
          3
          ·
          edit-2
          15 days ago

          These are arguments talking past each other. Sure 1 useful comment and 9 redundant ones can be better than zero, but comments are not reliable and often get overlooked in code changes and become misleading, sometimes critically misleading. So often the choice is between not enough comments versus many comments that you cannot trust and will sometimes tell you flat-out lies and overall just add to the difficulty of reading the code.

          There’s no virtue in the number of comments, high or low. The virtue is in the presence of quality comments. If we try to argue about how many there should be we can talk past each other forever.

    • 01101000_01101001@mander.xyz
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      15 days ago

      While this is true, an alternative is to name your variables and functions descriptively so that when you see number_of_cats you know that variable is the number of cats, and buyAnotherCat() is a function that increases the number of cats.

  • Fades@lemmy.world
    link
    fedilink
    arrow-up
    14
    ·
    15 days ago

    Reminds me of every fuckin PR I do for the Indian contractors that were sold to us as “senior devs” but write code like a junior and you better believe every other line has the most obvious fucking comment possible

    • Shirasho@lemmings.world
      link
      fedilink
      arrow-up
      7
      ·
      15 days ago

      Better than writing beginner level crap that is at the same time super cryptic and not documenting at all. We have a bunch of that in our codebase and it makes me wonder why these devs are writing extension methods for functionality already built into the standard libraries.

    • Shirasho@lemmings.world
      link
      fedilink
      arrow-up
      2
      ·
      15 days ago

      Better than writing beginner level crap that is at the same time super cryptic and not documenting at all. We have a bunch of that in our codebase and it makes me wonder why these devs are writing extension methods for functionality already built into the standard libraries.

    • rbitsOP
      link
      fedilink
      arrow-up
      10
      ·
      edit-2
      15 days ago

      Lol that’s exactly what this was. I wrote this python script, and he went through and added comments like this a day before the deadline.

      Not trying to throw shade on him though, it’s more the university’s fault for not explaining what makes a useful comment. I just thought it was funny

  • r00ty@kbin.life
    link
    fedilink
    arrow-up
    10
    arrow-down
    1
    ·
    16 days ago

    When people read my code, they usually say they like that I comment so much, it makes it easier to understand what’s happening.

    I say, I comment so much because my memory is terrible. It’s for me!

    • sping@lemmy.sdf.org
      link
      fedilink
      English
      arrow-up
      4
      ·
      15 days ago

      I’ve worked in a few startups, and it always annoys me when people say they don’t have time to do it right. You don’t have time not to do it right - code structure and clarity is needed even as a solo dev, as you say, for future you. Barfing out code on the basis of “it works, so ship it” you’ll be tied up in your own spaghetti in a few months. Hence the traditional clean-sheet rewrite that comes along after 18-24 months that really brings progress to its knees.

      Ironically I just left the startup world for a larger more established company and the code is some of the worst I’ve seen in a decade. e.g. core interface definitions without even have a sentence explaining the purpose of required functions. Think “you’re required to provide a function called “performControl()”, but to work out its responsibilities you’re going to have to reverse-engineer the codebase”. Worst of all this unprofessional crap is part of that ground-up 2nd attempt rewrite.

      • r00ty@kbin.life
        link
        fedilink
        arrow-up
        4
        ·
        15 days ago

        Ironically I just left the startup world for a larger more established company and the code is some of the worst I’ve seen in a decade. e.g. core interface definitions without even have a sentence explaining the purpose of required functions. Think “you’re required to provide a function called “performControl()”, but to work out its responsibilities you’re going to have to reverse-engineer the codebase”. Worst of all this unprofessional crap is part of that ground-up 2nd attempt rewrite.

        I think this is actually quite common in commercial code. At least, for most of the code I’ve seen. Which is why I laugh most of the time when people imply commercial code is better than most open source code. It’s not, you just cannot see it.

  • Tarogar@feddit.de
    link
    fedilink
    arrow-up
    15
    arrow-down
    11
    ·
    16 days ago

    There is usually no such thing as too many comments. There is a point to keep them to the point though

      • sping@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        4
        ·
        15 days ago

        Well on Reddit, programmerhumor was mostly populated by people weirdly proud of how bad they are at their job, so I don’t see how Lemmy was going to be different.

        • Tarogar@feddit.de
          link
          fedilink
          arrow-up
          2
          ·
          15 days ago

          Not to mention the fact that it’s programmer Humor. Not programming advice. which means that there are usually less serious comments to be found that may or may not be good advice. But I suppose some people have no sense of humour.

      • Tarogar@feddit.de
        link
        fedilink
        arrow-up
        1
        ·
        15 days ago

        You know, you do you in Humor communities. I personally don’t expect to find the most serious of comments under posts in those.

        Anyhow…Naturally there is a good argument to be made about making good comments. And that it may be a good idea to not comment things that are probably obvious. Just so that the file is a shorter read.