Home > Archive > PHP Language > December 2004 > Coding convention
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Joshua Beall 2004-12-18, 12:48 pm |
| Consider the following code (contained in a class method):
switch($sectionType)
{
case 'layout':
return $this->getLayoutSection($sectionName);
break;
case 'content':
return $this->getContentSection($sectionName);
break;
}
Obviously neither break is going to get execute, because the method will
return before it gets to them.
I have gotten into the habit of putting breaks at the end of every case in a
switch, even if it is not necessary (as the above). I have it somewhere in
the back of my head that this is the "proper" way to do things. But now
that I think about it, I have to ask, is this true? Is it consider good
practice to always end case statements with a break, even when not
necessary?
I'd like to hear others' thoughts on this. Thanks!
Sincerely,
-Josh
| |
|
| Janwillem Borleffs wrote:
> IMO, good coding practices imply omitting unnecessary code. When the break
> is never reached, just keep it out.
I strongly disagree.
Good coding practices imply readability and code maintainability, and
often DEMAND the opposite ("redundant" code).
The proper construct IS:
switch($foo) {
case 'layout':
//do something
break;
case 'content':
//do something
break;
}
If you omit the "break" statement, your construct will rely on the fact
that "do something" interrups flow to work.
The above example is actually pretty AWFUL in its design.
Something better migh look like:
return $this->getSection($sectionName, $sectionType);
I don't see the point of passing two semantically similar pieces of
information (section name and type) in such different ways. Might as
well use a single method getSection() and pass it all the info it needs.
(achieving the same in ONE line of _understandable_ code).
regards, f.
--
Cujo.
<fra@despammed.com>
<http://www.cujo.it>
PGP signed / encrypted mail welcome:
PGP Public Key: <http://www.cujo.it/pgp.txt>
| |
| Janwillem Borleffs 2004-12-18, 12:48 pm |
| This thread proves that code conventions are also a matter of taste. What
works for me certainly doesn't have to work for others. I, for one, don't
have any problems omitting a break statement when it isn't used and
inserting it when needed.
And when I say that I totally dislike the switch statement (in any language)
because of its (IMO) ugly syntax, many people will agree and many will
disagree.
Keeping your code readable, involves good documentation and compact code.
Adding a break to a switch doesn't dismiss the necessity of good
documentation and vice versa. But this is my opinion...
JW
| |
| CJ Llewellyn 2004-12-18, 12:48 pm |
| "Janwillem Borleffs" <jw@jwscripts.com> wrote in message
news:41c0569e$0$61454$b83b6cc0@news.euronet.nl...
> This thread proves that code conventions are also a matter of taste. What
> works for me certainly doesn't have to work for others. I, for one, don't
> have any problems omitting a break statement when it isn't used and
> inserting it when needed.
>
> And when I say that I totally dislike the switch statement (in any
language)
> because of its (IMO) ugly syntax, many people will agree and many will
> disagree.
Although a switch structure can lack flexibility, i.e. only one argument per
structure it is certainly preferable to a large number of elseif statements.
| |
| CJ Llewellyn 2004-12-20, 3:56 pm |
| "Janwillem Borleffs" <jw@jwscripts.com> wrote in message
news:41c0569e$0$61454$b83b6cc0@news.euronet.nl...
> This thread proves that code conventions are also a matter of taste. What
> works for me certainly doesn't have to work for others. I, for one, don't
> have any problems omitting a break statement when it isn't used and
> inserting it when needed.
>
> And when I say that I totally dislike the switch statement (in any
language)
> because of its (IMO) ugly syntax, many people will agree and many will
> disagree.
Although a switch structure can lack flexibility, i.e. only one argument per
structure it is certainly preferable to a large number of elseif statements.
| |
|
| What the heck do you use instead of a switch? Yes, the syntax isn't worthy
of Titian, but come on! It's perfectly functional.
have you thought of interior decorating? :)
"Janwillem Borleffs" <jw@jwscripts.com> wrote in message
news:41c0569e$0$61454$b83b6cc0@news.euronet.nl...
> This thread proves that code conventions are also a matter of taste. What
> works for me certainly doesn't have to work for others. I, for one, don't
> have any problems omitting a break statement when it isn't used and
> inserting it when needed.
>
> And when I say that I totally dislike the switch statement (in any
> language) because of its (IMO) ugly syntax, many people will agree and
> many will disagree.
>
> Keeping your code readable, involves good documentation and compact code.
> Adding a break to a switch doesn't dismiss the necessity of good
> documentation and vice versa. But this is my opinion...
>
>
> JW
>
>
>
| |
| Berislav Lopac 2004-12-21, 3:55 am |
| Janwillem Borleffs wrote:
> Good documentation, as mentioned before, can be used to indicate
> pitfalls where necessary...
As the old saying goes, documentation is like sex: When it's good, it's
great; when it isn't good, it's still better than none.
Berislav
| |
|
| "Janwillem Borleffs" <jw@jwscripts.com> wrote in message
news:41bf7bd9$0$98135$ee9da40f@news.euronet.nl...
>
> IMO, good coding practices imply omitting unnecessary code. When the break
> is never reached, just keep it out.
>
> JW
>
I have to disagree too - if you cease to return the value beforehand, you
have to alter your switch structure. Keep it as the syntax says, even if
you can get away with it. Most other languages would fail if you tried
that.
dave
| |
|
| No developer would just assume a break wasn't needed and remove it. That's
just silly. This is where the whole problem comes in.
If everyone obeys the syntax and doesn't try to cut corners, all these
problems disappear. It's when people try and get "fresh" with it that it
screws up. If you keep it by the book, when you pass it on, the next
developer doesn't have to first learn your particular take on the syntax -
they can just get on with it.
"Brett Foster" <fosterb.no.s.p.a.m@ioctl.ca> wrote in message
news:32amc8F3jfp1iU1@individual.net...[color=darkred]
> Cujo wrote:
>
>
> Yes, except unreachable statements are bad redundance because break
> implies the execution continues when clearly that isn't intended. If you
> were to remove the return, for example, you would still break your code
> because the continues execution would do something that was now different.
>
> switch (...) {
> ...
> case CONSTANT:
> // return;
> break;
> ...
> }
> //do something that wasn't indended for CONSTANT!
>
> Worse yet, adding a break would possibly cue a developer (yourself or
> somebody else) that the return statement could be removed without
> consequence when this may or may not be the case.
>
> In any event I think this is moot: Properly documented code would probably
> avoid the pitfalls of either style.
>
> Brett
>
| |
|
| You'd use comments to highlight the fact that you have to watch out for
where you freaked with the syntax and did something not recommended by the
documentation, for no benefit? Damn.
Slight overkill, don't you think? Just put the break in, and you don't need
lengthy comments saying why the developer felt it OK to remove breaks from a
switch, deviating from the standard.
"Janwillem Borleffs" <jw@jwscripts.com> wrote in message
news:41c05123$0$30704$18b6e80@news.euronet.nl...
> Oli Filth wrote:
>
> In which case, the developer would insert the break...
>
> Good documentation, as mentioned before, can be used to indicate pitfalls
> where necessary...
>
>
> JW
>
>
>
| |
|
| As we're talking about an interpreted language, that doesn't really apply ;)
"Brett Foster" <fosterb.no.s.p.a.m@ioctl.ca> wrote in message
news:32alcvF3ihk45U1@individual.net...[color=darkred]
> Janwillem Borleffs wrote:
>
>
> Agreed. It's also an error in some compiled languages to have unreachable
> code.
>
| |
| Janwillem Borleffs 2004-12-21, 8:56 am |
| d wrote:
> What the heck do you use instead of a switch? Yes, the syntax isn't
> worthy of Titian, but come on! It's perfectly functional.
>
So is eval(), but that doesn't mean I will use it without searching for
other options first.
JW
| |
| Brett Foster 2004-12-21, 8:56 am |
| d wrote:
> You'd use comments to highlight the fact that you have to watch out for
> where you freaked with the syntax and did something not recommended by the
> documentation, for no benefit? Damn.
I call bullshit. I may be wrong, but PHP makes no references to this in
the documentation for switch.
>
> Slight overkill, don't you think? Just put the break in, and you don't need
> lengthy comments saying why the developer felt it OK to remove breaks from a
> switch, deviating from the standard.
In java, for example, that is considered a major syntax error. On the
ohter hand GCC (C99?) does not.
So what coding standard do you go by? We might all be php coders here,
but a lot of us also write code in other languages. Thus unified coding
standards which support a wide range of platforms and environments are
needed. Break, after return would not be one I would include for reasons
in my previous post.
Brett
>
> "Janwillem Borleffs" <jw@jwscripts.com> wrote in message
> news:41c05123$0$30704$18b6e80@news.euronet.nl...
>
>
>
>
| |
| ScratchMonkey 2004-12-28, 3:56 pm |
| Brett Foster <fosterb.no.s.p.a.m@ioctl.ca> wrote in news:32amc8F3jfp1iU1
@individual.net:
> Worse yet, adding a break would possibly cue a developer (yourself or
> somebody else) that the return statement could be removed without
> consequence when this may or may not be the case.
Agreed.
Source code serves two functions: Communicating with the computer, and
communicating with the maintenance programmer. If someone hands me code
with redundant statements, I assume that either the original programmer
didn't know what he was doing or he was dealing with some quirk of his
tools.
Good code will tell you how something is done. Good comments will tell you
why it was coded that way and not some other. Code is the "how", comments
are the "why". Anything that looks quirky, like a dead code path, needs a
comment to explain why it's there.
|
|
|
|
|