[webkit-dev] Pointers and self-documenting code
rniwa at webkit.org
Fri Jul 6 14:33:11 PDT 2012
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?
> > dubious.
> > Is it correct for the font size to be zero if the page doesn't exist?
> > dubious.
> > Adding null checking only makes sense if you have a good story for what
> > 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
> 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
> > may know that the property is non-null from context (the value of some
> > 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
> > 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
> 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
> 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();
Note that Editor is a member variable of Frame and we just return &m_editor
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev