[webkit-dev] …Inlines.h vs …InlineMethods.h

[Geoffrey Garen]

>> (5) Adopt the convention that any function that is not as trivial as "int x() { return m_x; }" moves out of the class declaration.
> 
> How about we simplify this slightly to:
> 
> (5) Adopt the convention that any function that is nontrivial should be moved out of the class declaration.
> 
> We can give an example as to what might constitute trivial if we wish (e.g. is a one liner), but I think leaving a little wiggle room to allow developers to apply common sense would be a good thing.  While moving all complex functions out of class definitions sounds good, for some small classes being able to leave some very simple functions in the class declaration might not hurt, and might make the code easier to work with.  E.g.:
> 
> int y()
> {
> 	ASSERT(m_y != BAD_VALUE);
> 	return m_y;
> }

If possible, I'd like to establish clarity on what "trivial" or "nontrivial" means. This can save us debates in future patch reviews about what's "trivial enough".

To me, "trivial" means short. My straw-man proposal is "one-line functions only".

Failing that, I would at least like to pick some number. Maybe 6 lines, since that's just enough for a branch with an early return.

Thought complexity notwithstanding, non-trivial functions mainly get in the way of reading an interface because they take up space. "int x() { return m_x; }" is fine by me because it doesn't add any lines of code over "int x();". Notably, the next shortest function possible in WebKit style after one line is five lines. That means that I see 5X less of the class declaration in one screenful of code, and I have to do 5X more scrolling before I can see the data members in a class. To me, that's a significant blow to readability for a slight improvement in write-ability. Given that reading is more common than writing, I'm inclined to argue that >1 line functions are not worth it.

In general, I think brevity in class declarations is particularly important. I often find myself needing to read all of the public interfaces of a class, or look at a declaration in relation to a prior "public" or "private" keyword, or scroll past the interface declarations to get to the data members. (In contrast, I rarely need to read all of the function implementations of a class at once, or scroll to a specific lexical location among a set of function implementations.) Within some limits, I'm willing to write code more slowly so I can read declarations more quickly.

Geoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121105/faec8900/attachment.html>