[webkit-dev] Pointers and self-documenting code

[Ryosuke Niwa]

On Fri, Jul 6, 2012 at 2:26 PM, Joe Mason <jmason at rim.com> wrote:

> > From: Filip Pizlo [fpizlo at apple.com]
> > Sent: Friday, July 06, 2012 4:52 PM
> > To: Joe Mason
> > Cc: WebKit Development ‎[webkit-dev at lists.webkit.org]‎
> > Subject: Re: [webkit-dev] Pointers and self-documenting code
> >
> > It's not at all clear that this is correct.
> >
> > Is it correct for the font size to be zero if the frame doesn't exist?
>  Seems
> > dubious.
> >
> > Is it correct for the font size to be zero if the page doesn't exist?
>  Seems
> > dubious.
> >
> > Adding null checking only makes sense if you have a good story for what
> the
> > code ought to do if the pointer in question is null.
>
> Well, yes, but that's not the point of the example.  I thought about
> adding a comment, "or some suitable default," but I figured that would be
> pedantic.
>
> Regardless of whether my example default was a good one, it's clear that
> dereferencing null and crashing is NOT the correct thing to do.
>
> > This is a questionable policy.  Often object properties have transient
> > nullness.  They may be null at time T1 and non-null at time T2, and the
> caller
> >  may know that the property is non-null from context (the value of some
> other
> > field, the fact that it's performed some action that forces the field to
> > become non-null, etc).
>
> In this case the caller should specifically assert that the property is
> not null, to let the person reading the code know that it's a possibility
> that's been considered and it's believed to be impossible.
>
> > Thus statically enforcing the non-nullness of fields is likely to just
> make
> > the code more complicated.  And it doesn't buy anything.
>
> It buys a lot!  It buys clarity. It makes the code less fragile. It's a
> lower barrier to entry, because less knowledge is needed to understand the
> code.  In some cases it provides a compile-time correctness guarantee,
> which is a good thing - not in all cases, but sometimes is better than
> never.
>
> There are three categories of accessor:
>
> 1. Those that can never return null
> 2. Those that can potentially return null, and in circumstances complex
> enough that developers can't usefully keep track while writing algorithms
> 3. Those that can potentially return null, but only in circumstances that
> are well defined and easy to reason about (the "transient nullness" you
> mention)
>
> For type 1, I argue that we should return references to indicate this
> statically.  I don't see how this makes the code more complicated.
>

This change seems valuable. I've seen a lot of code & patches where people
did something along the line of:

Editor* editor= m_frame->editor();
if (!editor)
    return;

Note that Editor is a member variable of Frame and we just return &m_editor
in editor().

- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120706/79604117/attachment-0001.html>