[webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo
mjs at apple.com
Wed Jun 19 01:28:37 PDT 2013
On Jun 18, 2013, at 10:16 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> On Tue, Jun 18, 2013 at 7:20 PM, Simon Fraser <simon.fraser at apple.com> wrote:
>> On Jun 18, 2013, at 7:11 PM, Darin Adler <darin at apple.com> wrote:
>>> On Jun 18, 2013, at 7:05 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>>> Why don't we call it requireStyleResolver() instead?
>>> I’m warming to this idea. Maybe we can use “require” as a term of art, analogous to the way we use “create”, to mean “create if not already created”.
>> Since the fact that it returns a reference implies that it must create something if necessary, the “required” part of the name seems redundant. Why not just
>> StyleResolver& styleResolver()
>> requireStyleResolver() sounds like it would return a bool.
> True. But it's important to differentiate a simple inline accessor and a lazily-create function because it's very easy to write code like:
> if (styleResolver().x())
> and incur two function calls when we could have done
> StyleResolver& resolver = styleResolver();
> if (resolver.x())
> On the other hand, I've started to think that maybe we can simply forbid the former style altogether in the style guide so that we'll never have to think about whether a given function is inline or not.
I don't think possible lazy creation is a good reason to decorate the name. Functions should be named for what they do, not their presumed efficiency.
I am also not sure we need a style guideline about putting things into variables. If it makes a difference in a hot code path, then sure, but most of the time, the more concise code is better.
> - R. Niwa
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev