Remove unused style guide from readme file

Most of the code is already following chromium style guide as is so let's
remove this vestige from the past.

Bug: none, this is just an internal documentation change
Reviewed by: Antonio Gomes, SeungSeop Park, Zhang-hoon Oh

Change-Id: Ic79461f3f48395e8dac5025cf35dbabb8800f856
Signed-off-by: Balazs Kelemen <b.kelemen@samsung.com>

diff --git a/tizen_src/README.md b/tizen_src/README.md
index 2711318..0d6c92c 100755 (executable)
--- a/tizen_src/README.md
+++ b/tizen_src/README.md
@@ -95,63 +95,5 @@ You need to install GStreamer packages from tizenrepo.
 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.