Coding style
-----------
-In the public API implementation, we use the chromium coding style as a base
-(see: http://www.chromium.org/developers/coding-style). This is a good and
-consistent style. However, coming from WebKit and Blink, it seems like it has
-some disadvantages regarding readibility. For that reason we have some
-exception from it's rules.
-
-Our extra rules are these:
-
-1. We put starting braces of functinos and methods on it's own line
-
- *Bad*
-
- void MyFancyStuff() {
- ...
- }
-
- *Good*
-
- void MyFancyStuff()
- {
- ...
- }
-
-2. We do not keep the 80 character limit on line lenghts. It hurts readibility.
- There is no strict rule, but plese do break lines in a sane manner.
- A soft limit on about 120 characters is reasonable.
-
- *Bad*
-
- void RenderWidgetHostViewPort::GetDefaultScreenInfo(
- WebKit::WebScreenInfo* results)
-
- *Good*
-
- void RenderWidgetHostViewPort::GetDefaultScreenInfo(WebKit::WebScreenInfo* results)
-
-3. Do not name function params in function declarations if the role of the argument is clear.
-
- *Bad*
-
- void LaunchRocket(const Rocket& rocket);
-
- *Good*
-
- void LaunchRocket(const Rocket&);
-
-4. We do not require header guards to contain the full path of the header.
-
- *Bad*
-
- #ifndef EFL_INTEGRATION_SOME_MORE_NESTED_DIRS_MY_HEADER_H
- #define EFL_INTEGRATION_SOME_MORE_NESTED_DIRS_MY_HEADER_H
-
- *Good*
-
- #ifndef MY_HEADER_H
- #define MY_HEADER_H
-
-5. If a file is coming directly from WebKit (headers for example) it's acceptable to
- completely ignore fixing it's style.
+Internally we use the chromium coding style: http://www.chromium.org/developers/coding-style.
+For public headers we follow efl style.