all 36 comments

sorted by: hot top controversial new old
[–] 108 points 1 year ago (7 children)

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...

  • source
  • hideshow 7 child comments
  • [–] 48 points 1 year ago (4 children)

    i like to imagine it says

    we don't use this, but if you delete it everything in this file breaks

  • source
  • parent
  • hideshow 4 child comments
  • [–] 17 points 1 year ago (1 child)

    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

  • source
  • parent
  • hideshow 1 child comment
  • [–] 63 points 1 year ago (4 children)

    Is the function called is_even()?

  • source
  • hideshow 4 child comments
  • 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
    # ...
    
  • source
  • parent
  • [–] 56 points 1 year ago (7 children)

    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.

  • source
  • hideshow 7 child comments
  • [–] 8 points 1 year ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 1 year ago* (last edited 1 year 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.

  • source
  • parent
  • [–] 8 points 1 year ago* (3 children)

    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

  • source
  • parent
  • hideshow 3 child comments
  • [–] 29 points 1 year ago

    Holy mother of functions

  • source
  • [–] 24 points 1 year ago (4 children)

    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.

  • source
  • hideshow 4 child comments
  • [–] 12 points 1 year ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 1 year 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.

  • source
  • parent
  • [–] 5 points 1 year 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.

  • source
  • parent
  • that's some PTSD right there. just leave that closed as long as you can

  • source
  • [–] 19 points 1 year ago (1 child)

    Those lines are mostly comments, right? Right?

  • source
  • hideshow 1 child comment
  • [–] 13 points 1 year 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.

  • source
  • [–] 10 points 1 year 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.

  • source
  • [–] 8 points 1 year ago

    I have no memory of this place.

  • source
  • [–] 8 points 1 year ago

    get date switch case

  • source
  • [–] 6 points 1 year ago

    I can smell it from here

  • source
  • [–] 3 points 1 year ago

    It's a private function and you weren't invited. No need to look closer

  • source