On Nov 3, 2012, at 10:09 AM, Mark Lam <[email protected]> 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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev