• Fonzie!@ttrpg.network
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      1 month ago

      Okay now I get the joke.
      I hate these kind of people.

      By the way, your ``` both need to be on their own, separate line

        • Fonzie!@ttrpg.network
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          1 month ago

          It renders correctly on the web as well for me.

          But the ``` being on their own line is how to write it properly, as stated this website among many others.

          This way, you can put the intended programming language on the same line as the first ```, ensuring proper colour coding!

          Ex.

          echo "Hello $name\n";
          
          echo "Hello $name\n";
          

          EDIT I checked on mobile, it rendered odd on Jerboa for me:

          Screenshot of essteeyou@lemmy.world their comment in the Jerboa client before the edit

          Now it is fixed:

          Screenshot of essteeyou@lemmy.world their comment in the Jerboa client after the edit

  • JasonDJ@lemmy.zip
    link
    fedilink
    arrow-up
    15
    ·
    1 month ago

    My comments are just the code that didn’t work but I don’t want to delete yet because I might make it work except I never will be cause I already rewrote it so it does.

  • Sparky@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    1 month ago

    Hey thanks for reminding me I made a clock squared in blender about 2 years ago

    yes there is an error in the image, and no I’m not telling you where it is

  • linkhidalgogato@lemmy.ml
    link
    fedilink
    arrow-up
    6
    ·
    1 month ago

    basically how it feel when a professor requires u comment every single line of code u write to explain it. I know people tend to drop out of real engineering to do programing but an entire 4 years of this bullshit as opposed to just a couple classes sounds way worse than calc 3 or differential equations.

    • Urist@lemmy.ml
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 month ago

      The only problem with courses like calc 3 and differential equations (in my experience, as a mathematician) is that they are cheating somewhat. By cheating I mean relying on inadequate, flawed or entirely omitted proofs. How can the students truly understand something if they are not presented the whole story (or at least reference)?

      The good thing about these courses are that there are usually no shortage of relevant exercises!

      • linkhidalgogato@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        1 month ago

        u could be right calc 3 was alright, pretty fun actually but differential equations i still dont get at all, maybe i should try learn it on my own now with more time and no pressure.

        • Urist@lemmy.ml
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 month ago

          I detested differential equations. However, that was more due to how it was presented than the underlying, surprisingly, beautiful math.

  • sjh@sh.itjust.works
    link
    fedilink
    arrow-up
    3
    ·
    1 month ago

    Commenting code is a super important habit to get into—it not only helps others understand your thought process but also makes it easier for you to pick up where you left off if you revisit the code later. Plus, well-commented code can significantly reduce the onboarding time for new developers on a project. Remember, comments should explain the “why” behind the code, not just the “what.” For instance, stating why you chose a particular algorithm or data structure can be far more helpful than just labeling it. According to a study by SmartBear, 44% of developers regard poorly documented code as a top cause of project delays, so it’s definitely worth the extra effort!

    • doktormerlin@feddit.org
      link
      fedilink
      Deutsch
      arrow-up
      2
      ·
      1 month ago

      But it’s also important to learn that comments should be brief and concise. We have one file from an ex-dev in which there are 750 lines of code and 2000 lines of comment, when someone wants to maintain this code they always have a hard time because this many comments are taking up so much screen real estate that you can’t find the code that actually does stuff

  • jonathanvmv8f@lemm.ee
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    1 month ago

    Asking as a newbie programmer: how do you suggest we write comments that explain the ‘why’ part of the code? I understand writing comments explaining the ‘what’ part makes them redundant, but I feel like writing it the former way isn’t adding much help either. I mean, if I created code for a clock, is writing “It helps tell what time it is” better than writing “It is a clock” ?

    It would really help if someone could give a code snippet that clearly demonstrates how commenting the ‘correct’ way is clearly better than the way we are used to.

    • pixelscript@lemm.ee
      link
      fedilink
      English
      arrow-up
      8
      ·
      edit-2
      1 month ago

      I recognize three kinds of comments that have different purposes.

      The first kind are doc block comments. These are the ones that appear above functions, classes, class properties, methods. They usually have a distinct syntax with tags, like:

      /*
       * A one-line description of this function's job.
       *
       * Extra details that get more specific about how to use this function correctly, if needed.
       *
       * @param {Type} param1
       * @param {Type} param2
       * returns {Type}
       */
      function aFunctionThatDoesAThing(param1, param2) {
          // ...
      }
      

      The primary thing this is used for is automatic documentation generators. You run a program that scans your codebase, looks for these special comments, and automatically builds a set of documentation that you could, say, publish directly to a website. IDEs can also use them for tooltip popups. Generally, you want to write these like the reader won’t have the actual code to read. Because they might not!

      The second kind is standalone comments. They take up one or more lines all to themselves. I look at these like warning signs. When there’s something about the upcoming chunk of code that doesn’t tell the whole story obviously by itself. Perhaps something like:

      /* The following code is written in a weird way on purpose.
      I tried doing <obvious way>, but it causes a weird bug.
      Please do not refactor it, it will break. */
      

      Sometimes it’s tempting to use a standalone comment to explain what dense, hard-to-read code is doing. But ideally, you’d want to shunt it off to a function named what it does instead, with a descriptive doc comment if you can’t cram it all into a short name. Alternatively, rewrite the code to be less confusing. If you literally need the chunk of code to be in its confusing form, because a less confusing way doesn’t exist or doesn’t work, then this kind of comment explaining why is warranted.

      The last kind are inline comments. More or less the same use case as above, the only difference being they appear on the same line as code, usually at the very end of the line:

      dozen = 12 + 1; // one extra for the baker!
      

      In my opinion, these comments have the least reason to exist. Needing one tends to be a signal of a code smell, where the real answer is just rewriting the code to be clearer. They’re also a bit harder to spot, being shoved at the ends of lines. Especially true if you don’t enforce maximum line length rules in your codebase. But that’s mostly personal preference.

      There’s technically a fourth kind of comment: commented-out code. Where you select a chunk of code and convert it to a comment to “soft-delete” it, just in case you may want it later. I highly recommend against this. This is what version control software like Git is for. If you need it again, just roll back to it. Don’t leave it to rot in your codebase taking up space in your editor and being an eyesore.

    • Ethan@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 month ago

      My comment game has gotten far better since I started doing live code reviews. Essentially I ask myself, “Would I feel the need to explain this to someone during a code review?” and if the answer is yes I add a comment.

    • marlowe221@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 month ago

      “Why” comments make more sense as application complexity grows.

      You also have to consider interaction of the code with other external systems - sometimes external APIs force you to write code in ways you might not otherwise and it’s good to leave a trail for others on your team (and your future self…) about what was going on there.

      • something_random_tho@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 month ago

        100%. I also like to leave comments on bug fixes. Generally the more difficult the fix was to find, the longer the comment. On a couple gnarly ones we have multiple paragraphs of explanation for a single line of code.

    • MotoAsh@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 month ago

      IMO, the most important parts are to document the actual intent of the code. The contract of what is being documented. Sure, it’s only so useful in perfectly written code, but NO code is perfect, and few will come through later with full context already learned.

      It makes it sooo mich easier to know what is intended behavior and what is an unchecked edge case or an unexpected problem. If it’s a complicated thing with a lot of fallout, good documentation can save hours of manually lining up consequences and checking through them for sanity.

      You might say, “but that’s indication of bad code!”. No. Not really. Consequences easily extend past immediate code doing things as trivial as saving data to the database without filtering, or having a publicly available service. Even perfectly coded things come up with vulnerabilities all the time due to underlying security issues. It’s always great to have an immediate confirmation of what’s supposed to happen whether it’s immediate code or some library with a new quirk in a new version.

    • flashgnash@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 month ago

      “tells the user the current time” would be an excellent comment for a clock

      I’m not the best at commenting my code, but generally I just try to think of what information I’d want to know if looking at this 10 years from now

      Imo comments are best used sparingly, don’t bother commenting something that anyone with a basic understanding of programming would understand straight away by reading the code

      Functions should generally be commented with what parameters are and what they’re for, plus what they output

      use reqwest::Client;
      
      // create a http client class that all other files can import 
      // so as to only create one instance globally 
      
      pub struct HttpClient {
          client: Client,
      
      }
      impl HttpClient {
              pub fn new() -> Self {
                  HttpClient {
                      client: Client::new(),
                  }
              }
      
              pub fn client(&self) -> &Client {
                  &self.client
      
              }
      
      }
      

      Here’s an example where if I were to stumble onto this file 10 years from now, I might think wtf is this looking at it out of context, the comment explains why it exists and what it’s used for

      (we’ll ignore the fact I totally didn’t just add this comment because I suck at commenting personal projects)

    • TheDoctor [they/them]@hexbear.net
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 month ago

      I often use comments as ways to say, “I know this is cursed, but here’s why the obvious solution won’t work.” Like so:

      /**
       * The column on this table is badly named, but
       * renaming it is going to require an audit of our
       * db instances because we used to create them
       * by hand and there are some inconsistencies
       * that referential integrity breaks. This method
       * just does some basic checks and translates the
       * model’s property to be more understandable.
       * See [#27267] for more info.
       */
      

      Edit: to answer your question more directly, the “why not what” advice is more about the intent of whether to write a comment or not in the first place rather than rephrasing the existing “what” style comments. What code is doing should be clear based on names of variables and functions. Why it’s doing that may be unclear, which is why you would write a comment.

  • Russ O@cupoftea.social
    link
    fedilink
    arrow-up
    1
    ·
    27 days ago

    @Vordimous @linuxgal when I see this sort of thing when reviewing PRs, I write words to the effect of “tell me WHY it’s doing that, not WHAT it’s doing”. The “what” is usually obvious from the code and thus not worthy of comment. The “why” will enlighten your colleagues (and future you).

  • lnxtx@feddit.nl
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 month ago

    Self-explainable, when you aren’t writing spaghetti Perl scripts.

    • Swedneck@discuss.tchncs.de
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 month ago

      //forgive my sins, it took me 2 hours to nail down this arcane spell. if anyone touches this they will know my wrath
      =(/&)((//((%=)(&)%)(&()

    • darkpanda@lemmy.ca
      link
      fedilink
      arrow-up
      2
      ·
      1 month ago

      The code directly below:

      function getPathToUploadDirectory() {
        return config.tmp_path
      }
      
  • GooberEar@lemmy.wtf
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 month ago

    I know some folks are joking about and dunking on this, but in modern times, I have justification. Call me lazy, but I have found myself writing out these comments and then letting the AI take over to at least give me a sketch of an implementation. Works reasonably well and saves me a lot of time and effort. Mostly I don’t bother to remove them, though I usually edit them a bit.

    On the other hand, there are factions within my colleagues who steadfastly insist that commenting is unnecessary and to some degree even potentially harmful, and that if you feel the need to comment your code, it means your code should be improved so that it’s obvious what it is doing without the need for comments.

    • theherk@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      And your colleagues are probably correct with respect to this sort of «what it does» commenting. That can be counterproductive because if the code changes and the comment isn’t updated accordingly, it can be ambiguous. Better have the code be the singular source of truth. However, «why it does it» comments are another story and usually accepted by most as helpful.

      • ChickenLadyLovesLife@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        1 month ago

        if the code changes and the comment isn’t updated accordingly, it can be ambiguous.

        People always cite this as a reason comments are bad. In 30+ years as a developer I have seen (and participated in) a lot of failed software projects, but not once has a mismatch between comments and code been the actual cause of the failure. Moreover, the same logic could be applied to the names of methods and variables (“if the code changes and the method and variable names aren’t updated accordingly, it can be ambiguous”) but nobody ever suggests getting rid of that. At the end of the day, comments are useful for imparting information about the code to future developers (or yourself) that is too complicated to be adequately communicated by a method name.

      • Overshoot2648@lemm.ee
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 month ago

        I’ll add that you should have a comment anytime you are using some sort of algorithm to explain what it is and the expected result when it’s not intuitive or a complex math operation that isn’t immediately clear. Ex// I’m using Newton’s Method to approximate a solution to speed up the inverse square root

    • Benjaben@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      1 month ago

      Would you mind sharing a bit more about the workflow you’re describing? I’m on a “ask people how they’re using AI to help them dev” kick.

      Sounds like you’re using an agent integrated with your IDE, would you be willing to give specifics? And you’re talking about writing some comments that describe some code you haven’t yet written, letting the AI take a stab at writing the code based on your comments, and then working from there? Did I get that right?

      Happy for literally any elaboration you feel like giving :)

      • GooberEar@lemmy.wtf
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        1 month ago

        I use VS Code and GitHub Co-pilot and develop in a variety of different languages and frameworks. I’ve got lots of experience with some, but I’m less knowledgeable on others.

        So, having the AI assist with languages I am very familiar with is basically a way to save time and preserve my mental energy. For languages and frameworks I’m less experienced with, it speeds things up because I’m not having to constantly search how-tos and forums for guidance. And for languages/frameworks I have limited or no experience with, it can be a helpful learning tool that speeds up how long it takes to get ramped up.

        With this set-up, if I start writing a line of code and then pause for a moment, co-pilot kicks in and tries to autocomplete that line, sometimes even suggests the entire block of code. It’s really good at recognizing simple patterns and common boilerplate stuff. It’s less good at figuring out more complex stuff, though.

        However, I find that if I start out by writing a comment that explains what I’m trying to accomplish, and to some degree how to accomplish it before I start writing one of those more complex blocks/lines, the AI has a much higher success rate in returning helpful, functioning code. So, basically yes, I write the comment to describe code I haven’t written, and I’ll let the AI take over from there.

        This works for code, raw database queries, configuration files, and even for writing tests. I’m not an expert at building out Docker configurations for local development or configuring auto-deployment on whatever random system is being used for a project, but I can often get those things up and running just by describing in comments what I need and what I’m trying to accomplish.

        The VS Code co-pilot extension also has some context menu items that let you ask questions and/or ask for suggestions, which comes in handy for some things, but for me, typing out my intentions in comments and then letting the auto-complete kick in as I’m starting a line of code is faster, more efficient, and seems to work better.

        Granted, co-pilot also likes to try to auto-complete comments, so that’s sometimes funny just to read what it “thinks” I’m trying to do. And most of the time, I do remove my comments that were specifically to guide co-pilot on what I wanted it to do if they’re super redundant. And, at the end of the day, not everything co-pilot suggests is production-worthy, functional, nor does what I actually described. In fact, a lot of it is not, so you should expect to go back and fine tune things at a minimum. It’s just that overall, it’s good enough that even with all the supervision and revisions I have to make, it’s still a net positive, for now.

        • Benjaben@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          1 month ago

          Awesome, thank you! This largely matches my own experience, I’ve found it (Claude in my case) most useful in areas where I’m weakest. I haven’t tried this scaffolding-via-comments approach though, it sounds cool.

          Any experience with Cursor or other IDEs or agents? Was co-pilot a choice or just kinda a natural default?