12
rant1ng
5y

As an "OOP Programmer" you have one job to do:

Kill all the if statements.

Sometimes with fire.

Comments
  • 12
    I have several questions
  • 2
  • 5
    And let there be no checking of your parameters and null exceptions everywhere
  • 5
    Yis, kill the if loop
  • 3
    I somehow agree, but only to the extent of not having

    if (classInstance.Type() == someClassEnumerator.ParticularClassType()
    {
    // cast the generic class into another type
    // do something
    }

    That's absolutely bad and solvable by polymorphism
  • 0
    Aight chief imma head out now
  • 0
    You're doing some weird OOP
  • 2
    No:

    If (foo) {
    // 100 lines of code
    }

    Yes:

    if (!foo) {
    return;
    }

    Use early return / early exit.

    Code should be readable - if an if statement becomes too large (or a functions cyclomatic complexity) you are doing it wrong! (McCabe, 1974)
  • 0
    All I'm saying is..

    $myPoint = All::ImSayingIs('entire point')->You::can([
    Write::code()]mostly(like::this());

    If(You::ReallyWant())

    But::dontCheckMySyntax()
  • 0
    @Irene Needed to look MISRA up... Embedded devices standard for automotive. I think that the rule in MISRA is very.... Weird. I don't know why the rule exists?

    @Rant1ng Fluent methods have nothing to do with if statements ... :)
  • 2
    I don’t mind multiple returns if they are at the top of the method and it reduces a layer of nesting and the method is doing something simple like setting a few properties from a passed argument
  • 0
    @DLMousey I’m new here. What’s wrong with Dev.to? 😅
  • 0
    @Irene I find this ... Very controversial. In my experience it's quite the opposite that happens. When you return early, you can focus on the algorithm - you've split the function in two blocks, sanitizing / error handling and the algorithm.

    I don't think that this leads to bugs, quite the opposite is true - but this depends on language and how you return. I'm mainly a PHP dev, but have Basic knowledge of many other languages...

    How you return clarification:
    Early return by not using return is the source of many severe errors, including the famous and dreaded TLS errors. goto statement and other 'archaic' ways of 'rerouting' the program flow in a violent way.

    Language clarification:
    Especially in C / C++ (embedded this seems likely) I can think of bugs, especially regarding memory allocation. But C has variable declaration placement since STD 99 - still the propability exists that you forget to free unnecessary variables before returning...
  • 0
    Early returns are great for sanity checks
Add Comment