branching ≠ if ≠ conditional
They’re all related but can’t just be used interchangeably. “if” is a reserved keyword to indicate a specific syntax is expected. It’s not the semantics the author was trying to change, it’s the syntax, and the overall point is that you aren’t always required to use the specific “if” syntax to write code just like you’re not required to use “while” to achieve looping.
What’s the purpose of foo? Why an ambiguous single character variable? What if the property was there but the value was null? Why not use (assuming JS) optional chaining?
I’d approach it more like this:
function getWhatevrProp(userData) (
const default = { whatevr: "n/a" };
return { ...default, ...userData }.whatevr;
}
Sorry, read too fast the first time. It’s more likely Python. I also don’t know Python well enough to give recommendations on that.
Always love seeing the trope:
*writes awful code*
See! This is why this language sucks!
To each their own. Some won’t like the repeating code and some won’t like the distributed logic (i.e. you have to read every if and if-else statement to know when the else takes effect). I think the use of booleans like isDriverClose makes the repeated logic less messy and reduces inefficiency (if the compiler didn’t optimize for you).
It has conditionals not but actual if statements. Not really different in functionality but a more consistent style.
Hehe. COBOL doesn’t look too bad. Reads a bit like a person that’s never talked to another human being before.
If it’s closed source then it’s a losing battle to try and document code. I mean, do it when you feel it’s 100% necessary (e.g. complex code that you really can’t dumb down, “magic numbers” with a complicated backstory, test cases – it feels like that’s a different part of your brain so the transition is hard). Otherwise write code that almost reads like a sentence and don’t add complexity until you need it.
Actually makes me feel a bit better. Of all the issues this could be the easiest to tackle. Most other issues are completely above your pay grade, unless your boss/PO is adamant about always producing new features and tweaking old code is a waste of time.
Clearly the rest of the world are communists! It’s not us, it’s you! I’m not crying you’re crying! 😭😭😭
ISO 216 paper sizes work like this: https://www.printed.com/blog/paper-size-guide/
It’s so fucking neat and intuitive! How is it not used more???
Good enough in most cases. Too much info and it might as well give step by step instructions on how to hack you.
1, 3, 4 are good but out of laziness I’d personally use the first.
That really is unholy and I also couldn’t work there long if they thought that was OK (pun intended).
I would actually encourage error responses be in JSON if your 200 responses are JSON. Some clients are apt to always convert the body to JSON so it could avoid an exception on the client side not to throw a curveball.
To your point it’s most important that the content and Content-Type header match.
This is also going to make some devs (me) convulse when a PR is like, “small config change. updated 29 files”.
This was over 10 years ago, maybe 20. I wanted to pick up a new language and I seemed pretty driven, at the time, to hack a certain site. I think I gave up on it and as usual I enjoyed writing the code more than using the app.
It didn’t use webscraping or anything too sophisticated. I just applied a few dictionaries I found online and ran everything through a series of anonymous proxies. Very brute force.
Learned Python to try and hack into a porn site.
Even in this scenario it’s feasible for standards to change. ISBN-15 becomes a thing and suddenly you have books that never get an ISBN-13 so your primary key constraints cause an error for trying to insert a null. Granted, you can see a lot of these changes coming but again, they come on a schedule you don’t control.
Got hands on experience with this. Wasn’t my design choice but I inherited an app with a database where one of the keys was tied to a completely separate database. I mean at the time it probably made sense but the most unlikely of scenarios actually happened: that other database, the one I had zero control over, was migrated to a new platform. All of those keys were synthetic so of course they were like, “Meh, why we gotta keep the old keys?” So post-migration my app becomes basically useless and I spent 6 hours writing migration code, some of it on off hours, to fix my data.
So it’s questionable whether a foreign key of a completely different system is a natural key, but at the very least never use a key YOU don’t control.
How does “foo” mean “get”? Half the battle of writing correct code is writing code that’s easy to interpret. Do you always look at the guts of every function you’re about to use?