Skip to main content
Topic: Coding "standards" (Read 2521 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Coding "standards"

I was looking at the new game @Spuds is playing with :P (codacy.com).
The first suggestion I read was:
QuoteThe method censor uses an else expression. Else is never necessary and you can simplify the code to work without else.
QuoteWhy is this an issue?

Instead of using an else block, you can use an early return statement:
Code: [Select]
class Foo
{
    public function bar($flag)
    {
        if ($flag) {
            // one branch
        } else {
            // another branch
        }
    }
}
Rewrite without the else:
Code: [Select]
class Foo
{
    public function bar($flag)
    {
        if ($flag) {
            // one branch
            return;
        }

        // another branch
    }
}

And the question is: why should the second approach any better?
To me, the first one is more clear, and completely unambiguous (there are two possibilities and it's either one or the other) and less error prone (even though you delete something like for example the "return" there is no way the code from the "if" branch can enter the "else" part).
So, what's the rationale for using the second notation? ???
Bugs creator.
Features destroyer.
Template killer.

Re: Coding "standards"

Reply #1

I have been confused with these differences all the time., object oriented or otherwise. Sighed.

I think there should be no such thing as "standards". Coding should always be educating other users who is less learned in the coding itself. That is just my thinking though. No need to take it seriously.

Re: Coding "standards"

Reply #2

I see it done that way quite often but don't know the reasoning behind the approach.   I suppose in some controllers it helps that you don't have to look for any logic / control past the conditional since you are done.

Of course if you do it that way some analyzers will tell you that you have inconsistent return points as well, or returns of bool|null|int[]|mixed :P

Re: Coding "standards"

Reply #3

QuoteI think there should be no such thing as "standards". Coding should always be educating other users who is less learned in the coding itself.
That rabbit hole leads to a dark, dark place where code is different per project (and even within it!) while developers are confuse beyond belief. I may or may not be speaking from experience...

That's why I love the strict typing in PHP 7.

QuoteI see it done that way quite often but don't know the reasoning behind the approach
Which way, the second listed in the OP?

(The examples given are highly unorthodox)
LiveGallery - Simple gallery addon for ElkArte

Re: Coding "standards"

Reply #4

QuoteWhich way, the second listed in the OP?
Yup, fairly common and not just PHP, just one of the styles. 

We had "kind of" set a standard but then were less than firm in enforcing it, something we should address again in 2.0 so we can get things cleaned up.  We should probably pick one of the "standard" ones and just get on with it.

Re: Coding "standards"

Reply #5

I mix it up all the time. Sometimes I return early. Sometimes I have a single point of return. In general, I think you'll have less code if you use a single return point and it's easier to profile. Usually, I break that rule if I have to break out of a loop. As a rule of thumb, if my methods are returning different types, they probably should be split.