Coding convention

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>

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

"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.

"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
>
>
>

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...
> 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
>
>
>