On 9/20/12, Michael Matz <m...@suse.de> wrote:
> On Wed, 19 Sep 2012, Lawrence Crowl wrote:
> > On 9/19/12, Eric Botcazou <ebotca...@adacore.com> wrote:
> > > > The language syntax would bind the conditional into the
> > > > intializer, as in
> > > >
> > > >   if (varpool_node *vnode = (node->try_variable ()
> > > >                              && vnode->finalized))
> > > >     varpool_analyze_node (vnode);
> > > >
> > > > which does not type-match.
> > > >
> > > > So, if you want the type saftey and performance, the cascade
> > > > is really unavoidable.
> > >
> > > Just write:
> > >
> > >   varpool_node *vnode;
> > >
> > >   if ((vnode = node->try_variable ()) && vnode->finalized)
> > >     varpool_analyze_node (vnode);
> > >
> > > This has been the standard style for the past 2 decades and
> > > trading it for cascading if's is really a bad idea.
> >
> > Assignments in if statements are known to cause confusion.
>
> So?  Make it:
>
>   varpool_node *vnode = node->try_variable ();
>   if (vnode && vnode->finalized)
>     varpool_analyze_node (vnode);
>
> > The point of the change is to limit the scope of the variable
> > to the if statement, which prevents its unintended use later.
>
> I'm not worried about this.

It is helpful to have the language and the usage in concurrence.

Okay, so unless someone objects, I'll move the variable out when
it introduces a cacade.

> > Why do you think cascading ifs is a bad idea?
>
> Precedent.  Confusion in case of dangling else (requiring more {},
> and hence even more indentation).  Ugly.

I generally take ugly as an indication that the function needs
refactoring.

-- 
Lawrence Crowl

Reply via email to