[webkit-dev] …Inlines.h vs …InlineMethods.h
Darin Adler
darin at apple.com
Sat Nov 3 16:04:47 PDT 2012
On Nov 3, 2012, at 10:09 AM, Mark Lam <mark.lam at apple.com> wrote:
> 1. to keep class definitions more compact
> - so you can see more of the entire class (not that this is always possible anyway).
> - being able to see the entire class (when possible) can yield useful information about the shape of the class i.e. let's me see the architecture / design, not just the implementation.
> - having lots of inline functions bodies inside the class definition bloats the class significantly and makes it harder to see the shape. (again, a mental clutter issue). Of course, if you have editor tools that can hide the function bodies, this is not an issue.
Inline functions that are kept inside vs. outside class definitions is a separate issue from the in the same header file vs. in another header file.
I agree that class definitions are often significantly easier to read if all non-trivial function definitions are put outside the class. But requiring that all such function definitions be put into a separate file seems unduly awkward and heavy to me.
Maciej stated the reasons we have created such files in the past; the intent was not to put all inline functions in them. I would not want to create the many new files this new convention would require.
> By 1 liners, I mean something like:
>
> bool isFinished { return m_isFinished; }
>
> … but now am realizing that this is not allowed by the webkit coding style, which instead requires:
>
> bool isFinished
> {
> return m_isFinished;
> }
The WebKit coding style document might formally require that as currently written, but I think it’s a mistake and not consistent with the style we actually use in WebKit coding.
> I would propose updating the webkit coding style to allowing braces on the same line for the case of 1 line inline functions
We should. It’s already part of WebKit coding style, even though it seems not yet part of the formal WebKit coding style document.
-- Darin
More information about the webkit-dev
mailing list