RFC: Highlighting Fall-throughs

[Andrew Talbot]

Hi All,

I am thinking of marking any unmarked places in switch statements where
fall-through occurs. However, simply to do so would be to ignore the
question of whether each fall-through is intentional or an oversight.

I therefore propose to mark each new point with two comments (maybe
separate, maybe combined): one to state that fall-through occurs and the
other to point out that the validity of this particular fall-through has not
yet been checked, maybe something like:

select(x)
    {
    case 1:
        foo();
        break;
    case 2:
        bar();
        /* fall through */ /* unaudited */
    default:
        baz();
    }

Is this all good, or is there a better way?

Thanks,

[Alex Bradbury]

On 22 September 2011 22:20, Andrew Talbot  wrote:
> I therefore propose to mark each new point with two comments (maybe
> separate, maybe combined): one to state that fall-through occurs and the
> other to point out that the validity of this particular fall-through has not
> yet been checked, maybe something like:

Marking fall through cases sounds reasonable on the face of it to me.
I question the necessity of adding 'unaudited' comments though. I'd
imagine lint or one of the more sophisticated static analysis tools
could pretty easily give you a list of cases with fall-through without
a comment marking it as intentional.

Alex

[Andrew Talbot]

Alex Bradbury wrote:
> Marking fall through cases sounds reasonable on the face of it to me.
> I question the necessity of adding 'unaudited' comments though. I'd
> imagine lint or one of the more sophisticated static analysis tools
> could pretty easily give you a list of cases with fall-through without
> a comment marking it as intentional.
>
> Alex

I wondered if people seeing just a plain fall-through comment would assume
that it had been placed there by someone familiar with the code to indicate
that it was intentional and correct. Whereas, I may have placed it there not
necessarily knowing, or being able to discern, whether the programmer had
intended that behaviour or not. (Indeed, the absence of a comment in the
first place might be indicative of an oversight.) So I thought that marking
it as unverified in some way might be helpful.

[Andrew Talbot]

Andrew Talbot wrote:
> Alex Bradbury wrote:
> > Marking fall through cases sounds reasonable on the face of it to me.
> > I question the necessity of adding 'unaudited' comments though. I'd
> > imagine lint or one of the more sophisticated static analysis tools
> > could pretty easily give you a list of cases with fall-through without
> > a comment marking it as intentional.
> >
> > Alex

On further reflection, I think you are right. The single comment is enough 
on its own.

Thanks, Alex.

[Michael Stefaniuc]

Andrew Talbot wrote:
> Andrew Talbot wrote:
> > Alex Bradbury wrote:
> > > Marking fall through cases sounds reasonable on the face of it to me.
> > > I question the necessity of adding 'unaudited' comments though. I'd
> > > imagine lint or one of the more sophisticated static analysis tools
> > > could pretty easily give you a list of cases with fall-through without
> > > a comment marking it as intentional.
> > >
> > > Alex
>
> On further reflection, I think you are right. The single comment is enough 
> on its own.

Yes, because you do audit the code when you add it ;)
Marcus added a few of those too and fixed some others where the fall
through was a bug.

bye
    michael