Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
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 ? -
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. -
@jestdotty do you mean not all people are autists?
-
@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. -
@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. -
@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. -
@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. -
@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. -
@jestdotty the only thing that I claimed was bad is to abuse throw/catch for control flow.
-
@jestdotty you seem to not understand basic dev things even if explained to you like 3 times.
-
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). -
@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. -
@Root, my Dudette, I sometimes read you saying things like that, and I can't help but wonder - why do you still work there? At the same time, I beat myself for hypocrisy, because I used to work in a similar environment for 15+ years. Finally, it chewed through me, and now I can't work in IT at all, or I get psychosomatic symptoms like serious headaches, nausea, and vomiting. I mean, look out for yourself. There are jobs out there where you're praised for fixing what's broken, especially when nobody asked you to. I remember it felt 90% better to read all that old code when I was allowed to make it at least slightly better (or when I was 90% sure nobody would notice if I did).
-
@cprn Yeah. That is a very real fear of mine.
I feel so burned out that looking for work is enormously difficult, and simultaneously seemingly nowhere is actually hiring. I have been (almost exclusively) ghosted by every company I’ve applied to for years now.
I’ve been (not seriously) considering resigning from dev and working in a deli or bakery. But it sounds more tempting with each passing month. People who walk into a bakery are always happy to see you, and I could be making donuts and croissants. -
@jestdotty Nope, I live in the states. Small farming town touching a small city. Moved from Las Vegas, and it’s so much nicer here.
-
@jestdotty Yeah…
The country is a disaster atm by almost every metric. Makes sense the job market is crap too.
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
rant
root patches a parser
root swears oh my