You must log in or # to comment.
god, this code is awful. Who wrote this?
git blameOh
Been writing the same software for 20+ years now, don’t even need git blame to figure out what asshole wrote this shit.
Why is it always me? Haha
Yup there are certain patterns that I can just tell
I love that they called it “blame” lol. They knew what it would be used for.
Subversion tried to call it “annotate”, but that didn’t stick ;)
That exact chain of events happened to me at my last job and I audibly laughed realising it was my own code. To my own credit though, it was a file I had written four years prior which at that point was more than half my whole career in the past
If you aren’t ashamed of your work a year ago, you’re stagnating!
Sometimes you don’t even recognize your own trash, 6 weeks later.
Past me was a moron sometimes.
Still am. But I used to too
I have lately jokingly guessed when I see the particular style and confusion: it’s you isn’t it? And so far I have been right. The particular author’s magic has expired, and I see the same fault replicated everywhere he has been.
One of my coworkers is fond of using ternary expressions instead of “if” blocks. Even ones without an “else”. So I see things like:
condition ? someVar = "blah" : null;or
condition ? doSomething() : nullWhich should both just use “if” statements. Or my favorite:
condition ? someVar = "foo" : someVar = "bar"which should really be
someVar = condition ? "foo" : "bar"The last thing, that would be a “request changes” for me.
I haven’t seen him do it lately in any code I’ve reviewed but I do change it whenever I see it if I’m doing work nearby lol
UUUuuuuuh, I am not a programmer (you’re going to say “thank god”), but…
I sometimes even chain them. You can put yet another ternary operator in the else and keep going. You know, else-if.
So anyway, I can get ternary operators spanning 2 - 3 lines.
Oh, I also often have issues thinking of proper loops, so you’d see a few terribly usedgotostatements.Although I do remove ones that are obvious brain fart.
For example, quite obviousvoid example(bool true_or_false){ if(true_or_false){ //code if true } else{ //code if false } //other code }Well, I’ve already had my brain goof up even that once or twice. “How the fuck”, you’re asking?
void example(bool true_or_false){ if(true_or_false){ goto if_true; } //code if false goto end_false_if; if_true: //code if true end_false_if: //other code }The brain-fart if-else.
Dear lord lmao
especially your own code.
“This is obvious” I said. “Surely I won’t need to comment this,” I said.
The worst part is when I leave comments and still wonder wtf I was thinking.
That comes with experience. I rarely find things I wrote anymore where I could add or remove a comment.
Sometimes one does something in a certain way (which would otherwise be a shit way to do it) for very good reasons which are external to the code, be they requirements related, external upstream or downstream systems or due to existing system limitations or deployment environment.
More than a decade ago, I learned that even if one isn’t at all prone to put comments in the code, you should add comments for such reasons in that quirky code: months or years later that will yield exactly the reaction of this meme when you or somebody else sees that code (whilst you might remember why you did, somebody else will certainly not)
Maybe even more importantly, it allows other people to actually remove that crap if the reasons behind it don’t apply anymore, which they would otherwise not do because they would be fearful that the hacked-together pile of crap was needed for some reason elsewhere they were not aware of so they could not risk refactor it - most long lived codebases out there are riddled with crap which had pretty good reasons to be there back when it was done but it doesn’t anymore, but which newer people can’t just remove until they’ve gained a full understanding of the whole code base and how it’s wired to the rest (and, even then, there’s a risk that the reason is a requirement and if they just remove that code it breaks something that the users expect).
Even if you’re the kind of coder that thinks that “the code is self explanatory” (something which, by the way, betrays a lack of experience in the full life-cycle of software that has been in production for years and been worked on by several people) do your future self and others a favor by explaining the choices derived from external reasons (“Why has the auto engineer chosen to put the steering wheel in a British car on the right side?”) that led to code design which is NOT explainable by purely internal or good design or coding reasons.
(Or at least make it stupidly clear in the appropriate level of tests, which normally is requirements testing or integration testing)
If you’re really good and working in a proper professional environment (most programmer aren’t), consider tracing things back to the entries in the software requirements document, use cases or even elements of an use case, at least for the “quirky” choices.
Definitely. I’ve seen this advice summarized as “Comment ‘why’, not ‘how’” and it’s always helpful to come back to weird code and immediately understand these things.
Yeah, that wall of text is my rationale for doing exactly that.
As the sole programmer of a certain project, I often leave rant comment on what the previous programmer was thinking.
Electrical engineer: “what was that other guy thinking?”
Software engineer: “What was I thinking?” (It’s code from last night)
What was I thinking?-after every interruption that could have been an email
Electrician: “what was the engineer thinking?”
I’ll bitch and moan about my own work from a few months ago “before I knew better”.
In each of us, not two, but three. Paraphrasing Superfast matt, “that was done by past baahb, and he’s an idiot, but it matters more to future baahb, and that guy is an asshole.”
i hate when it’s not one person’s fault but like, ten years of bloat. who do i hate for that
Management
Manglement as I call them.
I wrote code today I know I will have to touch in 2 weeks. I’m already dreading it. that shits a mess.
“Which idiot would do that?”
* looks at git blame for the section and promptly shuts up *
Man past me should have done a better job
//Crappy hack to make this work immediately so management will stop breathing down my neck
Oh wait nevermind lol
Should have checked the
blamebefore running clang-format himself.
I don’t think you have to be a software engineer to understand that people do shit half-assed.
Am electrician can confirm
If I dont do it the homeowner tries to and I have to awkwardly nod instead of fixing the problem and that just takes so much longer
Two red flags for trades and swe and other work:
1 - never saying that they would have done it differently if not outright roasting the work 2 - letting someone else take over their project, willingly, and not because they’re busy. Assuming it’s not a pile of shit they don’t want to do.
Fun trick with Markdown. Put a double space at the end of a sentence so it formats the lines correctly.
- Double spaces
- allow for lists.
That’s the part I hate most about being a SWE. Just shut up and do your job. I’ve seen your code. You code like you read blogs for a living.
You code like you read blogs for a living.
Do you not?
No. I code like I know what I’m doing.
