• TheWonderfool@lemmy.world
    link
    fedilink
    arrow-up
    106
    ·
    5 days ago

    And what’s beautiful is that the one right under has a comment “we don’t use thi…”

    This code looks like so much fun to debug…

      • Taldan@lemmy.world
        link
        fedilink
        arrow-up
        17
        ·
        5 days ago

        we don’t use this without first writing proper unit tests for our changes, integrating them with the regression tests, and thoroughly documenting our changes for the next developer that has to work on this

        I’m an optimist, and it’s technically possible

    • Blackmist@feddit.uk
      link
      fedilink
      English
      arrow-up
      22
      ·
      5 days ago

      There’s one I found today that just reads “this is a fucking abortion”

      I don’t remember doing it, but it was almost certainly me.

  • kryptonianCodeMonkey@lemmy.world
    link
    fedilink
    arrow-up
    56
    ·
    4 days ago

    When I was in my 101 comp sci classes, one of my professors would say, “A function is meant to do one thing. So if your function doesn’t fit on the monitor in it’s entirety, that is a good indication your function is probably too complicated and/or doing too many things. Either simplify it or break it down further.” And that’s a rule I usually try to live by with my professional work too. So, anyway… I want to see the 4000k monitor this guy is using.

    • Pup Biru@aussie.zone
      link
      fedilink
      English
      arrow-up
      11
      ·
      4 days ago

      also depth of blocks: if i’m more than 2 or 3 indents deep, it’s probably got a bit too much logic to it and those comments should be converted to a function name

    • DarkAri@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      8
      ·
      4 days ago

      The rule of thumb I use is how likely am I to reuse some part of this code in the future? Also readability. Sometimes I like to just wrap some code in functions to make the code look neater. Other considerations are how often will this function be called? The overhead of calling a function is tiny but if a program is used by millions, everyday for many years, it’s sort of like not littering a bit to make the code a bit more inline. It is kind of nice to be able to mostly see what a piece of code does in a glance other than when it’s just wasteful.

      • kryptonianCodeMonkey@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        edit-2
        4 days ago

        Concise readability is usually my goal. Like if I have 12+ lines of code with a loop and some nested conditionals, recursively digging into buried directories, that probably takes a bit of thought to parse. So it is probably is better to move that to a function with a descriptive name like, “size, depth = get_directory_size_and_depth(filepath)”, that way the function name itself serves as it’s own comment/documentation describing what’s being done and, if you don’t really care about how the size and depth is aggregated, it abstracts that process into one line of code in the calling function that the reader can instantly understand without parsing the whole process. That goes doubly so when the function is generic like get_directory_size_and_depth(filepath) would be, and can be put in its own shared utilities file.

    • Gonzako@lemmy.world
      link
      fedilink
      arrow-up
      8
      ·
      edit-2
      4 days ago

      I personally go by the monocre that if it’s something important, it’d be all on one file as not to lose the train of thought when debugging it.

      As jumping around between files

      tends to break up thought lines

      also, the compiler likes it better when there’s less layers

    • Reuben@lemmy.nz
      link
      fedilink
      arrow-up
      32
      ·
      5 days ago

      Here, I optimised it:

      private function is_even(integer): 
          integer = 2;
          return True;
      
    • kryptonianCodeMonkey@lemmy.world
      link
      fedilink
      arrow-up
      17
      ·
      4 days ago
      def is_even(num:int) -> bool:
          if x < 0:
              x = x * (-1)
          if x == 0:
              return True
          elif x == 1:
              return False
          elif x == 2:
              return True
          elif x == 3:
              return False
          elif x == 4:
              return True
          elif x == 5:
              return False
          elif x == 6:
              return True
          elif x == 7:
              return False
      # ...
      
  • ilikecats@lemmy.sdf.org
    link
    fedilink
    arrow-up
    10
    ·
    4 days ago

    I have a rule in my NVim init.vim that it gets room for three line number digits. If it goes over, the screen shifts uncomfortably as warning. That works for my current projects.

  • Winter_Oven@piefed.social
    link
    fedilink
    English
    arrow-up
    24
    ·
    5 days ago

    imagine if the entire function is a single if-else statement which they kept adding onto, but could never refactor lest everything crashes down and burn.

    • Daedskin@lemmy.zip
      link
      fedilink
      arrow-up
      13
      ·
      5 days ago

      I once worked on a project doing firmware that a lot of people have likely used (printer firmware for a big-name company). One of the more trafficked functions was something like 1500 lines of “if-elseif-elseif…” with something like 13 or 14 different cases.
      It did end up getting refactored to something polymorphic and based on a configuration file to cut out any unnecessary steps, but it was like that for a while before I got there, and was like that for most of the year that I was part of the project.

      • thebestaquaman@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        4 days ago

        To be fair, I think massive “switchboards” can be relatively clean. The key is that each step contains little enough logic. 1500 lines of 13-14 cases means the average block was > 100 lines, and at that point I definitely agree that it should probably have been refactored a long time ago. Just splitting that into 13-14 smaller functions, and using the switchboard as a delegator could be completely fine.

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

      You’re dredging up some bad memories 😅

      Saw one once called something dangerously innocent like “run_validation” that turned out to be a 5K line hand built deserializer (no libraries used when then absolutely should have) with so many nested levels the editor put “expand this line?(2kb)” warnings at the end of most lines.

      In the original author’s defence the garbage being deserialized was an Eldritch horror. We eventually moved to JSON.

  • SailorFuzz@lemmy.world
    link
    fedilink
    arrow-up
    13
    ·
    5 days ago

    oh look, it’s the old codebase at my job

    Legit, the company banned people from using #region in their scripts because too many people were using it to hide massive amounts of slop code. Just giant fucking IF trees. Even though using it is hugely beneficial to keep things organized, especially if you use a lot of interfaces.