Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Plasticnova I’m keeping my calm.
-
@Demolishun don’t use an IDE. Easy win!
-
@Demolishun how about don't return from inside a case.
-
I have a real annoyance for all these devs that learn to do these things that add a safety layer for absolute beginners. It's stupid in that it either only applies for a tiny window of time or the dev is a perpetual beginner and shouldn't be a dev. The darker side of it is that some of these safety rituals do more to hide understanding as they hide where issues would occur.
-
@C0D4 That! Exactly that! One entry and one exit. nugh said
-
@horse Dunning-Kruger is something most people don't understand. Around two thirds of people exhibit the Dunning Kruger effect to a significant detectable degree for reasoning logically, they think they are logically right when they are logically wrong a significant amount of time. That applied to more than half the test subjects. It's safe to say the DK effect applies to everyone to some degree. It was only somewhere in the top 25% the effect overwhelmingly reverses.
The DK study is incomplete but I can share these observations: The things people are wrong about are not randomly distributed, people who with low skill that don't overestimate as much have a better chance at reaching high skill and people with a propensity to overestimate often do so across all domains. -
@RANTSMCPANTS I would assume this gets better with experience as people learn to fail. Or recognize the fault.
-
@Demolishun Only to some extent, it's somewhere between nature and nurture. However it's a lot worse with harder domains that push the limits of the intellect. Programming has a huge amount of depth and complexity. In many cases it can be a bottomless pit relative to simpler logic tests most likely used by DK which would be expected to only consisting of a few lines. Those would be a trivial amount of logic compared to the amount required for an application. I don't know however if they used any small but hard problems for their test.
-
-
@VaderNT Guard clauses are great! Cleans the code up, and makes functions more readable.
-
@fire-phoenix We do not "practice" programming, we *do* programming. There is no practice, good or bad. We have graduated from being children. We do not need to study or practice before the final exam.
-
@M1sf3t @C0D4 I do not follow that rule all the time, but it depends on the goal of a function.
If the function is more or less one big switch that only executes one case, I see no problem with returning in the switch.
If the return is instead of throwing an exception (some error state that is to common to be treated as an exception) I also often use return together with using blocks for cleanup.
But in a more complex method,if I find I want to use multiple returns I try to refactor the function into multiple function where I either fo not need multiple returns or can confine them into one of the first two cases.
That way every functions structure should be obvious and the multiple returns simplifies and reduces nesting.
But in the end, every one should find the way that helps them and their team to reduce the number of bugs. -
@tekashi You're trying to avoid the typo of accidentally assigning. It's so easy to grep for but instead your want to manually type ten thousand if statements ass backwards. I wish you the best of luck with that if that's your biggest programming concern. Even visually how hard is it to tell " = " from " == "? If you can't even manage that you shouldn't be allowed near a keyboard.
-
I know people like this too. I once had an argument over whether you need to put 'return' after 'throw' because "what if it doesn't break the execution"
And recently had another guy do
```
If(checkSomethingThatThrowsIfNull == null) {
Return null;
}
Why are there devs with supposedly years of experience in java that don't understand how control flow and the execution stack work?! -
@VaderNT source of an incredible amount of practical jokes too.
Related Rants
Coworker's whiteboard today
Fullstack dev: Hey I need your help with one of this method in the service layer (We use Java).
Me: Sure. What’s up!
Fullstack dev: When you get a user ....blah blah blah...
Me (typing code):
if (user != null) { ... }
Fullstack dev: Wait! This won’t work. You need to write this:
if (null != user) { ... }
In Java, you write like this. In JS it’ll work, not in Java.
Me: (also fuck this guy)
He’s among the famous devs in the company - (A very very very famous European bank).
I checked his commits for the frontend (React Native)
switch (some_expr) {
case foo:
return stuff()
break // <— note this
case bar:
return moreStuff()
break // <— note this
// more cases here with break after return statements
}
Me: Hey if you’re returning from a case why are you using a break. It’s dead code.
Fullstack dev: It’ll fall through otherwise.
———————
You’re a fucking dunce! Please drink a litre of Carborane in a rusty HIV infested container! Cheers!
PS More to come!
rant
fullstack dev
java