I need a way to explain to a coworker that nesting if statements beyond 3-4 is too much and needs to be re thought out. The dude is the biggest arrow head programmer I’ve ever seen. And he claims nothing is wrong with it, it works.. so what’s the problem.

Since we follow the rule of only one return per function he claims it’s the only way to accomplish the stuff he’s doing.. like if blah function passes... if blah function passss if blah functions passes do this then if blah functions

The if statements arnt just checking some variable conditions.. the conditions are checking returns of functions at each nested level the condition, executes a different function and thus checked for success.

Uggh I just don’t know how to explain to him it’s shit and needs to be re designed

Any ideas??

  • 7
  • 3
  • 3
    Those can be replaced with negation and else clause.
  • 5
    Tell him to read Clean Code, The Clean Coder (Robert C. Martin) and Code Complete (Steve McConnell).

    He'll find many other useful things in there.
  • 9
    I'm hoping there is a special place in hell for anyone who tries to force me to only have one return per method. Your methods should be short enough that 2 or 3 return calls are not obscuring the code.
  • 6
    It seems most people in here have never heard of cyclomatic complexity
  • 2
    @Robinha one return is more manageable. Unless it's an "everything is on fire" early return.
  • 5
    There are tools you can use to add checks for complexity and maintainability to your CI. You can fail the build if the complexity rating grows by more than a certain threshold.

    It's easier to enforce when it's a machine telling them to stop, rather than another human. They're less likely to take it personally or get defensive.
  • 1
    @Robinha there is
  • 0
    Duer, difrunt use caises!!!!!
  • 4
    @irene there are times when this is true and times when 2 or 3 returns are clearer. My main bugbear is when someone forces some prescriptive restriction on code for no good reason. Code can be clean without tieing the hands of developers.
  • 0
    @Robinha very specific and overall rare cases, imo. Generally there should not be two returns unless second one would drastically simplify the implementation without the risk of new obscure bugs.
  • 1
    @jallman112 elaborate more on that, please
  • 2
    @irene It's a new idea for me too. Just heard about it on a Python podcast. I got the impression it's based on other projects and libraries in other languages too.

    Podcast episode:

    Wily docs:
  • 0
    @jallman112 wow! The host is so monotonous and boring to listen to 😵😵😵
  • 2
    @irene 😂 Yeah, Tobias isn't the most exciting host. He does great interviews with a wide and interesting variety of people though.
  • 0
    One return per function and also no loop break is something that only Pascal programmers could have come up with, which proves that it's a bad idea.
  • 3
    @Fast-Nop I’m on the fence about how I feel about it, part of me tells me that multiple returns could increase the the speed thru a function in the even of an error or non satisfying conditions as it would not have to continue to check the rest of the conditions as it makes its way thru the function to the 1 exit return.

    The other part of me tells me if you design the ifs switches and conditions in a way you could achieve the same speed.

    From an embedded standpoint I understand why it’s done.. but the idea between 1 return seems outdated and can be solved with rules and standards, of common sense and don’t be dumb when doing it
  • 2
    @QuanticoCEO it's not only speed, it's also maintainability. First the checks for errors and constraints, return if something is wrong. Only then the business logic which isn't cluttered with error handling and much more readable.

    Occasionally, I also use forward goto if I need stacked error handling because of resource allocation. That eliminates code duplication for partially freeing resources and regular resource release.

    Sure, that's an issue with MISRA, but since MISRA is designed to code C like Pascal, it yields the same kind of crappy code as Pascal.

    Of course, that isn't an excuse for the shit in the screenshot either. ^^
  • 2
    @Fast-Nop MISRA is pretty stupid, Imo. I do automotive, so have to bear with that thing.
  • 3
    @Fast-Nop I totally agree, there’s soo much in MISRA that I am like who the F made that rule or this rule, and what programmer fucked up so bad that a rule needed to be created.. or was it a bunch or PHD fucktards sitting at a table like uggg yeah this should be like this or that..

    Yeah nothing excuses what’s in the screenshot, and I literally can’t explain it to him that the code is shit, cuz he says it’s completely logical, and procedural you know what I happening every step of the way blah blah blah... I’m like dude... you fucken redefined == to EQUALS cuz you claim it’s easier to understand... ugh noooo sir, when I’m reading code I scan for symbol and things that are done a certain way to get a sense of what is going on then dive into the logic of what’s happening.. I don’t see == when I read the word EQUALS. It doesn’t click, sure after you stop and think yeah it does.. but scanning looking for something my eyes just go past it as if it’s another variable.

    I’m trying tho to figure out a way, to satisfy MISRA, and the whole 1 return, but also keep it speedy, but also not arrowhead. I don’t know if it’s possible.

    I’m about ready to say fuck MISRA rule 15.5 as it’s only a “advisory” not mandatory rule.
  • 1
    @QuanticoCEO btw, that code is total garbage.
  • 1
    @irene MIRSA needs be rewritten. Many things in that is like wtf...
  • 1
    And this one
  • 2
    @irene ohhhh yeah I’m aware! Lol but I literally don’t know how to explain it to him. He’s really stubborn. And we are trying write our own corporate coding style/standards and he thinks his code is the best and we should be writing code his way. #facepalm
  • 2
    One return per function is an example of a pure cargo cult. No wonder you have trouble justifying your rules. Make your functions clear and make them do only one thing. Don’t optimize artificial metrics designed for large functions.

    You will find this advice in „Clean Code”, page 48, section „Structured programming”.
  • 2
    The best way to explain how code can be improved is to show them how you do it. „Your code is crap” never works.
  • 0
    @irene or the much nicer function, negation, return
Your Job Suck?
Get a Better Job
Add Comment