this post was submitted on 26 Nov 2023
12 points (100.0% liked)

Programmer Humor

19331 readers
20 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
top 18 comments
sorted by: hot top controversial new old
[–] magic_lobster_party@kbin.social 3 points 10 months ago (2 children)

x += 1; // Increases x by one

[–] autokludge@programming.dev 1 points 10 months ago* (last edited 10 months ago)

...Years later
x += config.increment; // Increases x by one

"""
config.yaml
increment: -2
"""
[–] towerful@programming.dev 0 points 10 months ago* (last edited 10 months ago) (2 children)

// increase the dynamically allocated memory space of a word sized integer stored at the memory address represented by the symbol "x" by the integer 1 and terminate the instruction

[–] Anders429@programming.dev 1 points 10 months ago (1 children)

Why the heck does it need to be dynamically allocated? Just put that puppy on the stack.

[–] towerful@programming.dev 1 points 10 months ago

That's what it used to do.
But it was a bug, and the code has been fixed.

[–] morrowind@lemmy.ml 1 points 10 months ago

Wait why is it dynamically allocated and why are you increasing the memory. Something is very wrong here

[–] onlinepersona@programming.dev 3 points 10 months ago (1 children)
[–] philm@programming.dev 1 points 10 months ago (3 children)

Yeah, but unironic...

If your code needs comments, it's either because it's unnecessarily complex/convoluted, or because there's more thought in it (e.g. complex mathematic operations, or edge-cases etc.). Comments just often don't age well IME, and when people are "forced" to read the (hopefully readable) code, they will more likely understand what is really happening, and the relevant design decisions.

Good video I really recommend: https://www.youtube.com/watch?v=Bf7vDBBOBUA

[–] Pickle_Jr@lemmy.dbzer0.com 2 points 10 months ago

Yeah, another way I've heard it phrased is comments are for explaining why you did things a certain way, not for explaining what it's doing.

[–] astraeus@programming.dev 1 points 10 months ago* (last edited 10 months ago)

This mindset is good, but unfortunately enforces bad programmers to leave their undocumented code in critical places where someone eventually has to figure out what the hell they were doing or refactor the whole damn thing because they got promoted to middle-management and can’t remember why they even wrote it.

[–] floofloof@lemmy.ca 1 points 10 months ago* (last edited 10 months ago)

If you're working with others, even simple code benefits from comments explaining what it's intended to do. Sure you can read code and get a good idea of what it seems to do, but you can't be sure that's what it was meant to do, or why it was meant to do that. Having a quick statement from the author enables you to work faster. And if you find a mismatch between the comment and the code, it's a smell that could mean a bug.

And for methods and functions it's particularly helpful to have a description at the top. Many IDEs will pop this up when you're using the method, so you can quickly confirm that it's appropriate for your needs and get your arguments in the right order.

I even comment code for myself because it will save me time when I return to the project months later.

No comments would be fine if you could trust that everyone writes code that does what it's intended to do and you can read code as quickly as you can read English. Maybe I'm a poor coder but I find neither of these is usually true.

[–] ILikeBoobies@lemmy.ca 2 points 10 months ago (1 children)
[–] thtroyer@programming.dev 1 points 10 months ago (1 children)
[–] docAvid@midwest.social 2 points 10 months ago

But an irreplaceable liability.

[–] Kolanaki@yiffit.net 1 points 10 months ago* (last edited 10 months ago)

"I'll just be extremely precise with my variable names. Then everyone will know exactly what everything does!"

Uses variable names like "INTEGER" and "STRING"

[–] EnderMB@lemmy.world 1 points 10 months ago

Comments don't describe the code. They describe the decision to use this business logic.

If you stick to good engineering practices, like small methods/functions, decoupling, and having testable code, you don't often need many comments to show what your code does. I always recommend a method signature, though, because you can save a few seconds by just saying that a block of code does, rather than me needing to read exactly how you turned one dict into another dict...

[–] Smoogs@lemmy.world 1 points 10 months ago

Wow the comments here sounds like you’re all a bunch of antisocial nightmares to deal with in rL.

[–] reverendsteveii@lemm.ee 1 points 10 months ago* (last edited 10 months ago)

`//Get CustomerInfo from CustomerRepository by Customer ID or else throw an CustomerNotFoundException

public CustomerInfo getById(String customerId) {

return customerRepository.getById(customerId).orElseThrow(new CustomerNotFoundException());

}`

This is the kind of pointless comment I see in my codebase all the time. Best I can tell, a couple of my coworkers like to plan out their code using comments, then backfill in the actual executable code. That's fine, but they leave the comments in when they add no value.

` public static LocalDate parseEndDateFromString(String dateString) {

    try {

        String[] split = dateString.split("-");

        //In order to get the last day of the desired month, we go to the first day of the next month, account for rollover, then subtract one day

        int month = Integer.parseInt(split[0]) == 12 ? 1 : Integer.parseInt(split[0]) + 1;

        return LocalDate.of(Integer.parseInt(split[1]), month, 1).minusDays(1);

    } catch (Exception e) {

        throw new RuntimeException("Invalid date format - must be MM-YYYY");

    }

}`

Stuff like this, otoh, is where comments are useful. The required format is obvious from the error message, the param and return from the method signature, the only part that requires a comment is the fiddly logic of accounting for the edge case where month == 12 and the rationale behind how we determine the last day of the month. As a rule, comments are for why something is being done, if it's not obvious, and for magic numbers. Code should tell you what code does.

edit: can anyone spot the bug that I introduced with that parseEndDateFromString() method?