• algernon@lemmy.ml
    link
    fedilink
    arrow-up
    186
    ·
    7 months ago

    Sadly, that’s not code Linus wrote. Nor one he merged. (It’s from git, copied from rsync, committed by Junio)

      • Epzillon@lemmy.ml
        link
        fedilink
        arrow-up
        156
        arrow-down
        2
        ·
        7 months ago

        Isn’t that from 1991 while the quote is from 1995? If we’re nitpicking maybe we shouldn’t time travel 🤓

        • rwhitisissle@lemmy.ml
          link
          fedilink
          arrow-up
          16
          ·
          7 months ago

          I’ve heard similar from the worst first year CS students you could ever meet. People talk out their ass without the experience to back up their observations constantly. The indentation thing is a reasonable heuristic that states you are adding too much complexity at specific points in your code that suggests you should isolate core pieces of logic into discrete functions. And while that’s broadly reasonable, this often has the downside of you producing code that has a lot of very small, very specific functions that are only ever invoked by other very small, very specific functions. It doesn’t make your code easier to read or understand and it arguably leads to scenarios in which your code becomes very disorganized and needlessly opaque purely because you didn’t want additional indentation in order to meet some kind of arbitrary formatting guideline you set for yourself. This is something that happens in any language but some languages are more susceptible to it than others. PEP8’s line length limit is treated like biblical edict by your more insufferable python developers.

    • laughterlaughter@lemmy.world
      link
      fedilink
      arrow-up
      21
      arrow-down
      1
      ·
      7 months ago

      Plus it shows three levels of indentation. Well… there is the extra one created by the compiler directives, but do they really count?

  • Alien Nathan Edward@lemm.ee
    link
    fedilink
    English
    arrow-up
    53
    ·
    7 months ago

    rules aren’t there to be enforced, they’re there so that when you break them you take a second to think about why.

        • Faresh@lemmy.ml
          link
          fedilink
          English
          arrow-up
          3
          ·
          7 months ago

          Why are you casting to void*? How is the compiler supposed to know the size of the data you are dereferencing?

          • xmunk@sh.itjust.works
            link
            fedilink
            arrow-up
            3
            ·
            edit-2
            7 months ago

            This would probably cause a compiler error…

            But assuming it doesn’t the context is p_ch = the bits above… the code declaring p_ch isn’t shown but I’m guessing that the value here is actuality a pointer to a pointer so nothing illegal would be happening.

            Lastly… C++ is really lacking in guarantees so you can assign a char to the first byte of an integer - C++ doesn’t generally care what you do unless you go out of bounds.

            The reason I’m casting to void* is just pure comedy.

      • fluckx@lemmy.world
        link
        fedilink
        arrow-up
        12
        arrow-down
        1
        ·
        edit-2
        7 months ago
        p = 1
        
        x = ++p
        // x = 2
        // p = 2
        
        p = 1
        x  = p++
        // x = 1
        // p = 2
        

        ++p will increase the value and return the new value

        p++ will increase the value and return the old value

        I think p = p + 1 is the same as p++ and not as ++p. No?

        • Tyoda@lemm.ee
          link
          fedilink
          arrow-up
          10
          ·
          edit-2
          7 months ago

          In C an assignment is an expression where the value is the new value of what was being assigned to.

          In a = b = 1, both a and b will be 1.

          a = *(p = p + 1)
          

          is the same as

          p += 1
          a = *p
          

          , so ++p.

          • fluckx@lemmy.world
            link
            fedilink
            arrow-up
            2
            arrow-down
            1
            ·
            7 months ago

            What I meant was:

            In the screenshot it said x = *(++p) and iirc that is not the same as saying x = *(p++) or x = *(p += 1)

            As in my example using ++p will return the new value after increment and p++ or p+=1 will return the value before the increment happens, and then increment the variable.

            Or at least that is how I remember it working based on other languages.

            I’m not sure what the * does, but I’m assuming it might be a pointer reference? I’ve never really learned how to code in c or c++ specifically. Though in other languages ( like PHP which is based on C ) there is a distinct difference between ++p and (p++ or p+= 1)

            The last two behave the same. Though it has been years since I did a lot of coding. Which is why I asked.

            I’ll install the latest PHP runtime tonight and give it a try xD

          • fluckx@lemmy.world
            link
            fedilink
            arrow-up
            3
            arrow-down
            1
            ·
            7 months ago

            Yes.

            p++ == p+= 1 == p = p + 1 are all the same if you use it in an assignment.

            ++p is different if you use it in an assignment. If it’s in its own line it won’t make much difference.

            That’s the point I was trying to make.

            • SpaceNoodle@lemmy.world
              link
              fedilink
              arrow-up
              5
              ·
              7 months ago

              No.

              ++p returns incremented p.

              p += 1 returns incremented p.

              p = p + 1 returns incremented p.

              p++ returns p before it is incremented.

    • marcos@lemmy.world
      link
      fedilink
      arrow-up
      11
      arrow-down
      3
      ·
      edit-2
      7 months ago

      That *++ operator from C is indeed confusing.

      Reminds me of the goes-to operator: --> that you can use as:

      while(i --> 0) {
      
      • letsgo@lemm.ee
        link
        fedilink
        arrow-up
        16
        arrow-down
        1
        ·
        7 months ago

        That’s not a real operator. You’ve put a space in “i–” and removed the space in “-- >”. The statement is “while i-- is greater than zero”. Inventing an unnecessary “goes to” operator just confuses beginners and adds something else to think about while debugging.

        And yes I have seen beginners try to use <-- and --<. Just stop it.

        • marcos@lemmy.world
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          7 months ago

          The sheer number of people that do not expect a joke on this community… (Really, if you are trying to learn how to program pay attention to the one without the Humor on the name, not here.)

          Well, I guess nobody expects.

  • ZILtoid1991@lemmy.world
    link
    fedilink
    arrow-up
    35
    arrow-down
    1
    ·
    7 months ago

    Why is multiple levels of indentation bad?

    IDK, but if the reason is “to break stuff into multiple functions”, then I’m not necessarily writing yet another single-use function just to avoid writing a comment, especially in time critical applications. Did that with a text parser that could get text formatting from a specifically written XML file, but mainly due to it being way less time critical, and had a lot of reused code via templates.

    • theherk@lemmy.world
      link
      fedilink
      arrow-up
      24
      ·
      7 months ago

      Like with everything, context matters. Sometimes it can indicate poorly structured control flow, other times inefficient loop nesting. But many times it is just somebody’s preference for guard clauses. As long as the intent is clear, there are no efficiency problems, and it is possible to reach the fewest branches necessary, I see no issues.

    • frezik
      link
      fedilink
      arrow-up
      21
      ·
      7 months ago

      It’s important to remember that Linus is primarily writing about C code formatting. C doesn’t have things that tend to create more deeply nested structures, such as a formal class syntax, or nested functions.

      Going too deep is still bad–as zea notes, it’s an indication of control structures run amok–but the exact number is dependent on the language and the context.

    • zea@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      20
      ·
      7 months ago

      Indentation implies there’s some control structure causing it. Too many control structures nested gets hard to mentally keep track of. 3 is arbitrary, but in general more indentation => harder to understand, which is bad.

    • dejected_warp_core@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      7 months ago

      Honestly I don’t mind the indentation since C isn’t going to give us many ways to address this with as little code.

      That said, with compilers that are good at inlining trivial functions, I really do appreciate the “it does what it says on the tin” approach to using functions on things like this. Even if they’re only used once. Comments would help too.

      The logic in these if statements is inscrutable on a cold read like this. To me, that’s a maintenance risk; imagine seeing a snippet this size on a PR. Having functions that name what the hell is going on could only help.

  • dejected_warp_core@lemmy.world
    link
    fedilink
    arrow-up
    35
    arrow-down
    8
    ·
    7 months ago

    One nit: whatever IDE is displaying single-character surrogates for == and != needs to stop. In a world where one could literally type those Unicode symbols in, and break a build, I think everyone is better off seeing the actual syntax.

    • PlexSheep@infosec.pub
      link
      fedilink
      arrow-up
      21
      arrow-down
      1
      ·
      7 months ago

      I think it’s a lineature. FiraCide does that for example, and I like it very much. My compiler and lsp will tell me if there is a bad char there. Besides, the linea tires take the same space as two regular characters, so you can tell the difference.

      It’s not the 90s anymore. My editor can look nice.

    • Tekhne@sh.itjust.works
      link
      fedilink
      arrow-up
      9
      arrow-down
      1
      ·
      7 months ago

      In a world where your IDE and maybe also compiler should warn you about using unicode literals in source code, that’s not much of a concern.

      VSCode (and I’m sure other modern IDEs, but haven’t tested) will call out if you’re using a Unicode char that could be confused with a source code symbol (e.g. i and ℹ️, which renders in some fonts as a styled lowercase i without color). I’m sure it does the same on the long equals sign.

      Any compiler will complain (usually these days with a decent error message) if someone somehow accidentally inserts an invalid Unicode character instead of typing ==.

    • Oinks@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      8
      arrow-down
      1
      ·
      7 months ago

      If your build fails because you can’t track down the literal in the code I would recommend just looking at the compiler error. I understand the concerns about == vs = more but the vast majority of LSPs (and some compilers) will catch that too.

      I have also yet to see any IDE enable ligatures by default, at least VS Code and the JetBrains suite both require opting into them even though their default fonts support them.

    • JK_Flip_Flop@lemmy.world
      link
      fedilink
      arrow-up
      7
      arrow-down
      1
      ·
      7 months ago

      I love ligatures but much prefer the ones that preserve the proper width of all the characters for this exact reason

  • RustyNova@lemmy.world
    link
    fedilink
    arrow-up
    27
    arrow-down
    2
    ·
    edit-2
    7 months ago

    While I totally agree with that philosophy, it heavily depends on the language.

    For Rust, my philosophy is more like this:

    • Impl + fn body don’t count, as well as async blocks if they span the whole function
    • do not nest more than one if statement. You probably better using guard clauses or matches
    • do not put loops into an if statement.
    • do not nest loops unless clearly shown to be (X, Y) indexing
    • method chaining is free
    • do not nest closures, unless the nested closure doesn’t have a {} block
    • do not use mod unless it’s test for the current module. No I don’t want to Star Wars scroll your 1000 line file. Split it.
    • calcopiritus@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      7 months ago

      Why have an async block spanning the whole function when you can mark the function as async? That’s 1 less level of indentation. Also, this quite is unusable for rust. A single match statement inside a function inside an impl is already 4 levels of indentation.

      • RustyNova@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        7 months ago

        Those async blocks exist when doing async in traits.

        And I never said I respected the 4 level of indentations. That’s exactly the point of those rules. Keep it lowly indented but still readable

      • Doods@infosec.pub
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        7 months ago

        A single match statement inside a function inside an impl is already 4 levels of indentation.

        How about this?

        The preferred way to ease multiple indentation levels in a switch statement is to align the switch and its subordinate case labels in the same column instead of double-indenting the case labels. E.g.:

        switch (suffix) {
        case 'G':
        case 'g':
                mem <<= 30;
                break;
        case 'M':
        case 'm':
                mem <<= 20;
                break;
        case 'K':
        case 'k':
                mem <<= 10;
                /* fall through */
        default:
                break;
        }
        

        I had some luck applying this to match statements. My example:

        
        let x = 5;
        
        match x {
        5 => foo(),
        3 => bar(),
        1 => match baz(x) {
        	Ok(_) => foo2(),
        	Err(e) => match maybe(e) {
        		Ok(_) => bar2(),
        		_ => panic!(),
        		}
        	}
        _ => panic!(),
        }
        
        

        Is this acceptable, at least compared to the original switch statement idea?

        • RustyNova@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          7 months ago

          It’s a lot less readable imo. As well than a cargo fmt later and it’s gone (unless there’s a nightly setting for it)

          • Doods@infosec.pub
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            7 months ago

            Formatters are off-topic for this, styles come first, formatters are developed later.

            My other reply:

            How about this one? it more closely mirrors the switch example:

            match suffix {
            'G' | 'g' => mem -= 30,
            'M' | 'm' => mem -= 20,
            'K' | 'k' => mem -= 10,
            _ => {},
            }
            

            How about this other one? it goes as far as cloning the switch example’s indentation:

            match suffix {
            'G' | 'g' => {
            	mem -= 30;
                   }
            'M' | 'm' => {
            	mem -= 20;
                   }
            'K' | 'k' => {
            	mem -= 10;
                   }
            _ => {},
            }
            
            • folkrav@lemmy.ca
              link
              fedilink
              arrow-up
              4
              ·
              7 months ago

              I mean, I use formatters everywhere I can exactly so I don’t have to think about code style. I’ll take a full code base that’s consistent in a style I dislike, over having another subjective debate about which style is prettier or easier to read, any day. So whatever cargo fmt spits out is exactly what I’ll prefer, regardless of what it looks like, if only for mere consistency.

        • lseif@sopuli.xyz
          link
          fedilink
          arrow-up
          2
          ·
          7 months ago

          i personally find this a lot less readable than the switch example. the case keywords at the start of the line quickly signify its meaning, unlike with => after the pattern. though i dont speak for everybody.

          • Doods@infosec.pub
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            edit-2
            7 months ago

            How about this one? it more closely mirrors the switch example:

            match suffix {
            'G' | 'g' => mem -= 30,
            'M' | 'm' => mem -= 20,
            'K' | 'k' => mem -= 10,
            _ => {},
            }
            

            How about this other one? it goes as far as cloning the switch example’s indentation:

            match suffix {
            'G' | 'g' => {
            	mem -= 30;
                    }
            'M' | 'm' => {
            	mem -= 20;
                    }
            'K' | 'k' => {
            	mem -= 10;
                    }
            _ => {},
            }
            
            • lseif@sopuli.xyz
              link
              fedilink
              arrow-up
              2
              ·
              7 months ago

              the problem is that, while skimming the start of each lines, nothing about 'G' | 'g' tells me that its a branch. i need to spend more time parsing it. mind you, this may simply be a problem with rust’s syntax, not just ur formatting.

        • calcopiritus@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          7 months ago

          Well, of course you can have few indent levels by just not indenting, I don’t think the readability loss is worth it though. If I had give up some indentation, I’d probably not indent the impl {} blocks.

          • Doods@infosec.pub
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            edit-2
            6 months ago

            I just got some idea yesterday regarding impl blocks, ready to be my respondent?

            I had a big impl block with 4 levels of indentation, so I cut the block, and replaced

            impl InputList {
                //snip
            }
            

            with mod impl_inputlist; and moved the impl block to a new file, and did not indent anything inside that block.

            The advantage this has over just not indenting the impl block in place, is that people will have difficulty distinguishing between what’s in the block and what’s outside, and that’s why the impl was moved to its own exclusive file, impl_inputlist.rs

            Maybe I am overstressing indentation. Ss there something wrong with my setup that prevents me from accepting 4-space indentation?

            I use:

            Editor: Neovide

            Font: “FiraCode Nerd Font Mono:h16” (16px fonts are addicintg)

            Monitor: 1366x768, 18.5 inch, 10+ years old, frankenstein-ly repaired Samsung monitor.

            Distance: I sit at about 40-60 Cm from my monitor.

            That leaves me with a 32x99 view of code excluding line numbers and such.

    • meteokr@community.adiquaints.moe
      link
      fedilink
      arrow-up
      5
      ·
      7 months ago

      I don’t know enough Rust to understand by what you mean by the last one. My understanding was that mod name was just declaring the module that this file depends on. Could you explain what I should do instead? Since your other statements I totally agree with, I should probably agree with the last one.

      • Killing_Spark@feddit.de
        link
        fedilink
        arrow-up
        8
        ·
        7 months ago

        mod name declares that the module should be compiled and reachable as a submodule of the current module. This assumes that you have a file or directory of the name in the right place. This is what you should do.

        You can also declare a module like this: mod name {...} where you just put the content in the block. The two are functionally equivalent, from the compilers perspective.

        • meteokr@community.adiquaints.moe
          link
          fedilink
          arrow-up
          1
          ·
          7 months ago

          I don’t understand how to follow this bullet point that I was replying to.

          do not use mod unless it’s test for the current module. No I don’t want to Star Wars scroll your 1000 line file. Split it.

          I already know what mod does in a basic sense, I wanted to know what the commenter meant by this.

          • Killing_Spark@feddit.de
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            7 months ago

            This point advocates against the use of mod with content in a file unless it is used for a testing module. A common pattern is to have the unit tests for a module inside the main module file. Tests in rust are just specially tagged functions. To avoid compilation costs in non-test builds and false unused code warnings you can put all test related code in a submodule and tag that module with #[cfg(test)]. That way the module will only be included and compiled if the crate is being compiled to run tests.

            The Star wars thing refers to scrolling long text files similar to the intro of the starwars movies where a long text is scrolled for the viewer.

            • meteokr@community.adiquaints.moe
              link
              fedilink
              arrow-up
              1
              ·
              7 months ago

              Oh so its just referring to writing the mod’s code in the same file the mod is declared in being bad form? That seems very reasonable; since the point of a module is code separation so it makes sense to always put it in its own file. Good, I’m already doing that at least!

          • RustyNova@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            7 months ago

            Oh, then you use and_then() or something similar.

            There’s also the possibility to use the guard clauses patern and do let <...> = <...> else {}.

            And finally, you can always split into another function.

            It’s not straight rules. It depends on what makes it more readable for your case.

  • Juice
    link
    fedilink
    arrow-up
    25
    arrow-down
    2
    ·
    7 months ago

    Broad generalizations aren’t for the people who make them, they’re for the suckers who consistently fall for them

  • Kimano@lemmy.world
    link
    fedilink
    arrow-up
    20
    ·
    7 months ago

    My personal code readability axe to grind is nested complex ternary operators.

    Every now and then I’ll see something like this

    return (checkFormatType(currentObject.type==TYPES.static||currentObject type==TYPES.dynamic?TYPES.mutable:TYPES.immutable)?create format("MUTABLE"):getFormat(currentObject));

    And I have a fucking conniption because just move that shit into a variable before the return. I get it when sometimes you just need to resolve something inline, but a huge amount of the time that ternary can be extracted to a variable before the ternary, or just rewrite the function to take multiple types and resolve it in the function.

    • Skullgrid@lemmy.world
      link
      fedilink
      arrow-up
      8
      ·
      7 months ago

      no but bro, the code complexity tool says that this scope has 14 complexity instead of 13, we gotta cram it in a single ternary for code legibility

    • lud@lemm.ee
      link
      fedilink
      arrow-up
      8
      ·
      7 months ago

      That example looks like the PowerShell equivalent of piping complex things around 20 times before actually doing something with the results.

    • dejected_warp_core@lemmy.world
      link
      fedilink
      arrow-up
      7
      ·
      edit-2
      7 months ago

      In a one-liner competition, sure.

      In my codebase? I’d pull a “let’s linger after standup about your PR” and have the coder sweat through a 10 minute soapbox about nothing before laying down the law.

      • Kimano@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        7 months ago

        Yeah, the annoying thing is the people who I generally have found to be the worst about stuff like this are old school Senior C developers, who still program like it’s 1987 and we have to fit everything into 4K of RAM.

        Fortunately there’s nothing like that in my code base, I just run into stuff like that periodically when I’m digging around in other team’s server code looking for something.

  • Nighed@sffa.community
    link
    fedilink
    English
    arrow-up
    20
    ·
    7 months ago

    This posts entire comment chain is an interesting example of people that have extensive knowledge in completely different areas of programming to me. And have some concepts I had never heard/thought of.

  • dariusj18@lemmy.world
    link
    fedilink
    arrow-up
    20
    ·
    7 months ago

    The number one thing that gets in my way of refactoring to function is figuring out what to name the functions takes too long.

    • Victor@lemmy.world
      link
      fedilink
      arrow-up
      8
      ·
      7 months ago

      Then perhaps the code you are trying to extract doesn’t make a clear and cohesive procedure. Maybe include more or less of the code, or rework the code into logical pieces or steps. Write the algorithm in human language first, then implement the steps using functions.

      🤷‍♂️ Or fnck it.

    • zea@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      3
      arrow-down
      1
      ·
      7 months ago

      Pick something and change it when inspiration strikes. Sometimes you need a big picture view of something to get the right abstractions or even just name things.

  • acockworkorange@mander.xyz
    link
    fedilink
    arrow-up
    12
    ·
    7 months ago

    You get one level at the get go because everything is in a function. So just two levels of indentation? A pretty basic if… for…if nesting has to be refactored? Into what? Goto? Should I sprinkle return statements all over the place?

    Y’all gotta understand that Linus is often kind of an ass.

    • macniel@feddit.de
      link
      fedilink
      arrow-up
      14
      arrow-down
      4
      ·
      7 months ago

      What’s wrong with Ligatures? It makes reading code a bit more tolerable.

      • Ephera@lemmy.ml
        link
        fedilink
        arrow-up
        13
        arrow-down
        2
        ·
        7 months ago

        I mean, I certainly wouldn’t give someone else shit for using ligatures, but personally, I don’t like them, because:

        • they break with monospacedness. Everything is in a nice grid and you’ve randomly got these character combinations that needlessly stick out.
        • they sometimes happen in places where they really shouldn’t.
        • they hide what the actual characters are. Especially, if go to edit that code, my brain will really struggle for a split-second when there’s a ‘≠’, then I delete one character and rather than the whole thing disappearing, I’m left with a ‘!’.
        • Faresh@lemmy.ml
          link
          fedilink
          English
          arrow-up
          2
          ·
          7 months ago

          they break with monospacedness

          The IDEs I’ve used had the ligatures be of the same character width as the original operator.

          • Ephera@lemmy.ml
            link
            fedilink
            arrow-up
            1
            ·
            7 months ago

            Oh, yeah, I meant that it makes two characters into one big one, visually reaching across two or three widths, or just having one of the characters larger than the usual grid, e.g. in := the equals sign reaches into the width of the colon.

            This reminds me of a recent Microsoft font¹, so naturally here’s a rant about that: They developed a feature, called “texture-healing”, which basically allows characters that normally need to cramp into one monospace width, like m or w, to reach into the space of neighboring characters, if those neighboring characters are narrow, like an i.

            In theory, not a terrible idea, but then you get this kind of hate crime:

            Obviously, might just be me again, but not having these letters align, just looks so much worse to me.

            ¹: It’s this font: https://monaspace.githubnext.com/

        • redfellow@sopuli.xyz
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          7 months ago

          Do you also get surprised when you backspace a tab and suddenly it removes more whitespace than 1 characters worth?

          Or did you learn it fast and really never think about it?

          I think it’s more a “getting used to” thing, that once learned, you don’t think about, but it makes things more readable.

          • Ephera@lemmy.ml
            link
            fedilink
            arrow-up
            4
            arrow-down
            1
            ·
            7 months ago

            Sure, I could get used to it. But it being more readable is not even true for me, because the thing I got used to instead, is that != is the unequals-operator. I see that much more often than .

            • redfellow@sopuli.xyz
              link
              fedilink
              arrow-up
              4
              arrow-down
              1
              ·
              7 months ago

              Studies show that ligatures improve readability, but I acknowledge that it’s likely untrue for outliers.

              • Ephera@lemmy.ml
                link
                fedilink
                arrow-up
                2
                ·
                7 months ago

                For monospace fonts? I’ve heard of such research for proportional fonts, where ligatures definitely make sense to me. But yeah, I wouldn’t assume such research to automatically translate to monospace.

    • redfellow@sopuli.xyz
      link
      fedilink
      arrow-up
      8
      arrow-down
      2
      ·
      7 months ago

      I mean, we read code more than we write it. You just vomitted over something that increases readability. Maybe a time for a rethink?