On 9/20/12, Michael Matz <[email protected]> wrote:
> On Wed, 19 Sep 2012, Lawrence Crowl wrote:
> > On 9/19/12, Eric Botcazou <[email protected]> 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
