Programmer Humor

37400 readers

20 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.

founded 6 years ago

MODERATORS

AgreeableLandscape@lemmy.ml

cat_programmer@lemmy.ml

457

Infallible Code (lemmy.ml)

submitted 1 week ago by sirico@feddit.uk to c/programmerhumor@lemmy.ml

165 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] FishFace@lemmy.world 16 points 1 week ago (16 children)

This is what Test Driven Development looks like

[–] normalexit@lemmy.world 13 points 1 week ago (11 children)

TDD has cycles of red, green, refactor. This has neither been refactored nor tested. You can tell by the duplication and the fact that it can't pass all test cases.

If this looks like TDD to you, I'm sorry that is your experience. Good results with TDD are not guaranteed, you still have to be a strong developer and think through the solution.

[–] barubary@infosec.exchange 5 points 1 week ago (5 children)

When you say "it can't pass all test cases", what do you imagine the tests look like?

[–] normalexit@lemmy.world 5 points 1 week ago (2 children)

In a world where this needs to be solved with TDD there are a few approaches.

If you were pair programming, your pair could always create a new failing test with the current implementation.

Realistically I would want tests for the interesting cases like zero, positive even, negative even, and the odds.

Another approach would be property based testing. One could create sequence generators that randomly generate even or odd numbers and tests the function with those known sequences. I don't typically use this approach, but it would be a good fit here.

Really in pair programming, your pair would get sick of your crap if you were writing code like this, remind you of all the work you need to get done this week, and you'd end up using modulus and move on quickly.

[–] barubary@infosec.exchange 4 points 1 week ago (1 children)

If you were pair programming, your pair could always create a new failing test with the current implementation.

But I'm not pair programming. And you can't always create a new failing test because int is a finite type. There are only about 4 billion cases to handle.

Which might take a while to type up manually, but that's why we have meta-programming: Code that generates code. (In C++ you could even use templates, but you might run into compiler recursion limits.)

More to the point, the risk with TDD is that all development is driven by failing test cases, so a naive approach will end up "overfitting", producing exactly the code required to make a particular set of tests pass and nothing more. "It can't pass all test cases"? It doesn't have to. For TDD, it only needs to pass the tests that have actually been written. You can't test all combinations of all inputs.

(Also, if you changed this function to use modulus, it would handle more cases than before, which is a change in behavior. You're not supposed to do that when refactoring; refactoring should preserve semantics.)

[–] normalexit@lemmy.world 2 points 1 week ago* (last edited 1 week ago)

Read the article about property based testing. It is the middle ground between what you are describing and practicality.

I often pair with myself, which sounds silly but you can write failing tests by yourself, it just isn't as fun.

[–] pivot_root@lemmy.world 1 points 1 week ago

you'd end up using modulus and move on quickly.

But where's the fun in that?

There are so many better ~~for obfuscation~~ ways of checking for oddness!

(a & 1) > 0
a.toString()[a.toString().length()-1] - '1' == 0
iseven(a)?(1==0):(1!=0)

load more comments (2 replies)

load more comments (7 replies)

load more comments (11 replies)