this post was submitted on 10 Jul 2024
1060 points (93.8% liked)

Programmer Humor

18962 readers
395 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
 
you are viewing a single comment's thread
view the rest of the comments
[–] Fades@lemmy.world 183 points 1 month ago* (last edited 1 month ago) (29 children)

WHY IS THE HEALTH INPUT PARAMETER A GODDAMN STRING?????????????

Why are you passing ‘%’ inside said goddamn string?!?! Not to mention the static reference instead of the actual instance.

Shame on you

[–] veganpizza69@lemmy.world 6 points 1 month ago (14 children)

The high level setter function should be made to handle both string and numeric values.

If it contains "%" it's a percentage value.

If it's a string without a "%" it's an absolute value and needs to be normalized.

If it's a numeric value, it's an absolute value.

If it's a numeric 100, it's 100%.

If it's a subunitary numeric value, it's a percentage.

[–] Skates@feddit.nl 4 points 1 month ago (1 children)

Oldman.setHealth("dicktits"); //normalize pls

Oldman.setHealth("-100±1%"); //make percentage pls

Oldman.setHealth(0.0); //it is subunitary, but undefined behavior - will it access the 'numeric value' overload, or the 'subunitary numeric value' overload?

Don't write your own code just yet.

[–] veganpizza69@lemmy.world 3 points 1 month ago

Oldman.setHealth(“dicktits”); //normalize pls

0

Oldman.setHealth(“-100±1%”); //make percentage pls

Reject operations.

Use absolute number to remove the minus. Math.abs()

Oldman.setHealth(0.0); //it is subunitary, but undefined behavior - will it access the ‘numeric value’ overload, or the ‘subunitary numeric value’ overload?

Same result either way, so whatever if branch is first.

Understand the purpose. If you want to kill the old man with 0, then there's no point to leaving it as 0.9%, understand the non-linear characteristics of life and death.

When you're dealing with the low level functions, sure, you can keep it simple. When you're reaching the surface of user input, you're either going to waste time with validation and error reporting, or you're going to waste time with interfaces that can handle more shit without complaining. There's no fool proof either way, but good luck pissing users off with endless docs.

Don’t write your own code just yet.

If your goal in programming is just to be a traffic cop between the user input and the database, all you're doing is building a virtual bureaucracy, the kind that people really hate and is easily generated with coding tools. Or you're just deferring the "smoothing out" burden to the UI developers.

load more comments (12 replies)
load more comments (26 replies)