30
Root
79d

I’m on this ticket, right? It’s adding some functionality to some payment file parser. The code is atrocious, but it’s getting replaced with a microservice definitely-not-soon-enough, so i don’t need to rewrite it or anything, but looking at this monstrosity of mental diarrhea … fucking UGH. The code stink is noxious.

The damn thing reads each line of a csv file, keeping track of some metadata (blah blah) and the line number (which somehow has TWO off-by-one errors, so it starts on fucking 2 — and yes, the goddamn column headers on line #0 is recorded as line #2), does the same setup shit on every goddamned iteration, then calls a *second* parser on that line. That second parser in turn stores its line state, the line number, the batch number (…which is actually a huge object…), and a whole host of other large objects on itself, and uses exception throwing to communicate, catches and re-raises those exceptions as needed (instead of using, you know, if blocks to skip like 5 lines), and then writes the results of parsing that one single line to the database, and returns. The original calling parser then reads the data BACK OUT OF THE DATABASE, branches on that, and does more shit before reading the next line out of the file and calling that line-parser again.

JESUS CHRIST WHAT THE FUCK

And that’s not including the lesser crimes like duplicated code, misleading var names, and shit like defining class instance constants but … first checking to see if they’re defined yet? They obviously aren’t because they aren’t anywhere else in the fucking file!

Whoever wrote this pile of fetid muck must have been retroactively aborted for their previous crimes against intelligence, somehow survived the attempt, and is now worse off and re-offending.

Just.
Asdkfljasdklfhgasdfdah

Comments
  • 9
    In some mysterious house:

    Bro1: Yeah we won't go bankrupt but I need a csv payments parser for our new client.

    Bro2: I'll copy paste our code to the new project and copy paste some more code, to get it working.

    Bro1: How long it would take?

    Bro2: 2-3 hours

    Bro1: Sweet, I'm going to grocery to buy some booze and we get wasted.

    Bro1: Bro

    Bro2: Bro

    ...15 years later...

    Root: wtf is this pile of shait ?
  • 10
    I think most people are simply not smart enough to spot logical duplications

    not all developers are made the same

    also though if management sucks they won't give a fuck. maybe they were high on weed
  • 2
    First time in legacy code? Lol I kid, but this seems like a typical Tuesday for me, as someone who maintains god awful bullshit written by the insane and incompetent.

    That is some truly overthought, overwrought bullshit though, I'll pour one out for you. Off by two csv parser? Shit, I hope you're not working with one of my predecessors.
  • 2
    I’ve seen this with fixed width column data where 1st row is file details, 2nd row is metadata, 3rd row was column headers, 4th + was data, last 3 rows is more metadata.

    Some people really want the world to burn.
  • 1
    Communication via throwing exceptions is something whose purpose is above me. And it can stay like that.
  • 4
    Reeks of incompetence.

    You should see the pile of shit I have to work on.

    "sure, anyone can become a programmer." But should they? lmao.
  • 0
    @jestdotty do you mean not all people are autists?
  • 3
    @Ranchonyx There is a rule written somewhere which says that throwing and catching exceptions should not be used for control flow. I think it’s somewhere in the msdn docs.

    Of course, 90% of C# std lib is written with thrown exceptions which incentivizes to use them as control flow. And naturally, 90% of production code does use exceptions for control flow.

    😔

    I’m glad that this trend is now slowly dying with modern languages and the Result type.
  • 0
    @jestdotty no, the Result type eliminates the need to use throw/catch for errors/exceptions.
    So you are free to use whatever error handling mechanism that fits best in a specific situation.
  • 1
    @jestdotty the issue us not that errors are used as control flow. It often makes sense to do so.
    The issue is that when your only error handling mechanism is throwing and catching, then you are forced to use throw catch as control flow if your use case is such that you want to use errors for control flow.
  • 0
    @jestdotty I don‘t dislike throw/catch.
    It‘s just that it‘s only one way to do error handling.
    Sometimes it‘s good to do error handling with throw/catch and sometimes it‘s bad. Depends on the use case.
    Problem is when you don‘t have a choice.
  • 1
    @jestdotty it‘s a design choice. Similar to how you structure your code or name your variables.

    Sometimes you want your errors to bubble up the stack and catch them at some point where you handle all the errors which occurred in different places. Then you use throw/catch.

    And sometimes you want to handle the error on the spot, exactly where it occurred, then proceed with the flow depending on the outcome. Then you can use the Result type for example.

    Pick the right tool for each situation, essentially.
  • 0
    @jestdotty the only thing that I claimed was bad is to abuse throw/catch for control flow.
  • 2
    Good rant OP
  • 1
    @jestdotty you seem to not understand basic dev things even if explained to you like 3 times.
  • 0
    if method throws Exception, hmm patterns everywhere. I feel you, I wasted 3 days because some mononolith HTTP0.9 API failed silently. The issue was a field too long, by one character. So yea
  • 1
    I think I'm too used to it to react in any way.

    Normally I just write tests, at least the happy path, as I read such code for the 2nd time (1st is "wtf, I'm lost") as a form of notes. Then I use those "notes" to rewrite it, the most atrocious parts at least, and commit with "routine optimizations, no logic changed" kind of comment that gets ignored by all forms of management.

    Rewrite while you read and you never have to get back to an utterly broken piece of code for the 2nd time.

    And whenever someone asks what stage are you at, just tell them you're still getting familiar with the code because it's convoluted, then flip the script on them and start asking questions they can't answer until they direct you to someone who wrote it. You don't need the answers, you probably don't want them, but it's a good way to get people off your back and make *them* look incompetent in the process (people assume incompetence when there are delays and with legacy there always are).
  • 0
    @cprn Yeah, I used to do things like that too. But I’ve been chewed out too many times for it here and told never to touch things that aren’t specifically listed in the ticket. I do sometimes anyway, and often get away with it, but it’s always a risk.

    The managers here review PRs, even when they aren’t devs (or worse: think they are because they coded on punchcards “back in the day”).

    I pray for meteors to squish them all.
Add Comment