[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Font dialog
From:       Clarence Dang <dang () kde ! org>
Date:       2005-06-24 10:11:14
Message-ID: 200506242011.14180.dang () kde ! org
[Download RAW message or body]

On Tue, 21 Jun 2005 07:09 pm, Thomas Zander wrote:
> On Tuesday 21 June 2005 10:03, Clarence Dang wrote:
> > On Fri, 17 Jun 2005 11:28 pm, David Faure wrote:
> > > On Monday 06 June 2005 23:06, pierre.stirnweiss_koffice@gadz.org
> > > wrote: int koLayoutTab::getOffsetFromBaseline()
> > > {
> > >         switch ( positionButtonGroup->selectedId() )
> > >         {
> > >         case 0:
> > >                 return 0;
> > >                 break;
> > > No need for break; after a return. Return already stops there and
> > > returns immediately. (You can remove many "breaks" in that file).
> >
> > Different school of thought I guess: :)
>
> I personally find this kind of avoiding future problems kind of silly; if
> you make this mistake 2 or 3 times; the next time check your change
> before you start compiling.

So you've never made this mistake again _ever_?

> If you disagree; they why not add { } around the case block?
> Or add ';' on every empty line, since some code may be written in front.

That's caught at compile time.  Forgetting a break is not.

Default fall through behaviour is a flaw with the C language that is, AFAICS, 
only exploited for bizarre optimisations hacks.  It's so error prone that it 
is only beneficial to protect against it.

> At the moment the code is less readable (the fact that the comment is
> added in the example I snipped should make that clear) and as soon as you
> start to edit a file I wrote (which does not have such things) then you
> will be in trouble due to wrong expectations.
>
> But thats just my opinion, naturally

You are right that this is just personal preference.  Obviously, I always 
check before changing switch/case code but an extra safeguard can't hurt.

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]