62
darwyyn
7d

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!

Comments
  • 1
    Well that’s annoying
  • 0
    @Plasticnova I’m keeping my calm.
  • 9
    If I don't use break my IDE complains... If I do use break it complains... Cannot win
  • 4
    @Demolishun don’t use an IDE. Easy win!
  • 6
    Or don't use a switch statement
  • 8
    If you go by the mdn docs you use break and not return. They don't even bring return up in that section.
  • 10
    @Demolishun how about don't return from inside a case.
  • 1
    Dunning-Kruger. That’s something that affects a lot of developers.
  • 2
    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.
  • 10
    One entry point, one exit. Simple thing really.
  • 4
    @C0D4 That! Exactly that! One entry and one exit. nugh said
  • 4
    @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.
  • 1
    @RANTSMCPANTS I would assume this gets better with experience as people learn to fail. Or recognize the fault.
  • 2
    @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.
  • 0
    I feel his pain in his code when a Java guy has to write JavaScript, just take it over from him he needs liberation.
  • 1
    MAYBE HE JUST NEEDS A BREAK?
  • 0
    And this is why we can't have nice things... Had a job like that, took a huge step back to find happiness again lol
  • 2
    @RANTSMCPANTS yea he could probably do with not returning for a while 🤔
  • 1
    @M1sf3t

    You mean?:

    @highlights

    while(someshit){

    return(crap);

    }
  • 0
    @Demolishun I think it's
    @highlight testing...
  • -1
  • 2
    @C0D4 "One entry point, one exit. Simple thing really."

    Interestingly just recently I had a short discussion with a junior dev about that.
    I don't see the value of that rule on its own. E.g. I prefer guard clauses at the top of a function over nested or complex if clauses.
  • 0
    Should use a break, even if you are returning. It is good practice.
  • 1
  • -1
  • 1
    @VaderNT Guard clauses are great! Cleans the code up, and makes functions more readable.
  • 1
    @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.
  • -1
  • 1
    @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.
  • 0
    Hes kinda right, its usually a good idea to

    if (null == thingThatCanBreak)
  • 2
    @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.
  • 1
    @tekashi off topic but not true actually.

    It’s a good idea only if are invoking a method of a nullable object. If you’re comparing a nullable using == it doesn’t matter.

    Common example:

    if (SOME_STRING_CONSTANT.equals(stringThatCanBeNull) { ... }
  • 1
    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?!
  • 1
    @RANTSMCPANTS "We do not "practice" programming, we *do* programming. There is no practice, good or bad."

    Ah, the multiple meanings of "practice". Always a good source for puns. 🙂
  • 0
    @VaderNT source of an incredible amount of practical jokes too.
  • 0
    This is gold this stuff. Break after return 😂😂😂
Add Comment