Replace spaces with tabstizen_4.0.m2_releasetizen_4.0.m1_releasetizen_4.0.IoT.p2_releasetizen_4.0.IoT.p1_releasesubmit/tizen_unified/20170308.100409submit/tizen_5.0/20181101.000004submit/tizen_4.0/20170828.110004submit/tizen_4.0/20170828.100004submit/tizen_4.0/20170811.094300submit/tizen/20161107.233654accepted/tizen/wearable/20161108.001429accepted/tizen/unified/20170309.033544accepted/tizen/tv/20161108.001407accepted/tizen/mobile/20161108.001352accepted/tizen/ivi/20161108.001450accepted/tizen/common/20161108.131525accepted/tizen/5.0/unified/20181102.020909accepted/tizen/4.0/unified/20170829.020006accepted/tizen/4.0/unified/20170816.011448accepted/tizen_wearableaccepted/tizen_tvaccepted/tizen_mobileaccepted/tizen_iviaccepted/tizen_commonaccepted/tizen_5.0_unifiedaccepted/tizen_4.0_unified

Tab policy [IDT_M_TAB] have changed from optional to mandatory and whole code
has to be adjusted.
doc/coding_rules.txt updated.
File access rights fixed

Change-Id: I7b855be9560e9b4f134294a1f97a70a50af578c1

1 files changed, 32 insertions, 32 deletions

diff --git a/doc/coding-rules.txt b/doc/coding-rules.txt
index 4f55843..9f8b70e 100644
--- a/doc/coding-rules.txt
+++ b/doc/coding-rules.txt
@@ -4,24 +4,24 @@
 Differences from Tizen rules are included as "Notes". For full description of
 each rule - please refer to Tizen documentation.
 
-[R01] [CMT_M_C89] Style for comment is the C89 "/* … */" style.
+[R01] [CMT_M_C89] Both comment styles are allowed : C89 "/* ... */" style & C99 "//" style
 Note: Temporary comments may use C99 style (TODO, FIXME etc.)
 
 [R02] [DEC_R_INL] inline keyword should sit between storage class and type.
 
-[R03] [IDT_R_TAB] Use tabs. All tabs are 4 characters. Indentation use only tab (No space key).
-Note: If possible use Smart Tabs, if not - 4-character tabs + alignment spaces
+[M01] [IDT_M_TAB] Use tabs. All tabs are 4 characters. Indentation use only tab (No space key).
+Note: If necessary use 4-character tabs + alignment spaces
 
-[R04] [IDT_R_SCH] Switch and case should be at the same indent.
+[M02] [IDT_M_SCH] Switch and case should be at the same indent.
 
-[R05] [IDT_R_LBL] goto labels aren't indented, allow a single space however.
+[R03] [IDT_R_LBL] goto labels aren't indented, allow a single space however.
 Note: No single space allowed
 
-[M01] [SPC_M_KWD] Keywords have following space rules
+[M03] [SPC_M_KWD] Keywords have following space rules
 -Put a space after (most) keywords (ex: if, switch, case, for, do, while).
 -Exception: Do not put a space after function like keywords, such as sizeof, typeof, alignof, __attribute__. -
 
-[M02] [SPC_M_OPR] Operators have following space rules
+[M04] [SPC_M_OPR] Operators have following space rules
 -Put a space around(on each side of) most binary and ternary operators
 -Example: = + -< > * / % | & ^ <= >= == != ? :
 -Do not put a space after unary operators
@@ -30,7 +30,7 @@ Note: No single space allowed
 -Do not put a space after cast operator
 -Do not put a space around the "." and "->" structure member operators.
 
-[M03] [SPC_M_SEP] Seperators have following space rules
+[M05] [SPC_M_SEP] Seperators have following space rules
 -Put a space after closing brace when it has anything on the line.
 -Exception : comma after closing brace '},'
 -Put a space after comma
@@ -38,50 +38,50 @@ Note: No single space allowed
 -Do not put a space after the function name in function calls.
 -Do not put space before open square bracket '['; and inside square bracket '[', ']'.
 
-[M04] [BRC_M_FTN] functions have the opening brace at the beginning of the next line.
+[M06] [BRC_M_FTN] functions have the opening brace at the beginning of the next line.
 
-[M05] [BRC_M_SMT] Statement brace: Open brace last on the line. The closing brace is empty on a line of its own.
+[M07] [BRC_M_SMT] Statement brace: Open brace last on the line. The closing brace is empty on a line of its own.
 -Exception: Where the closing race is followed by a continuation of the same statement, else should follow close brace '}',
 while should follow close brace '}'
 
-[M06] [BRC_M_EUS] Open braces for enum, union and struct go on the same line.
+[M08] [BRC_M_EUS] Open braces for enum, union and struct go on the same line.
 
-[R06] [BRC_R_SST] Do not unnecessarily use braces where a single statement will do.
+[R04] [BRC_R_SST] Do not unnecessarily use braces where a single statement will do.
 -Exception: if one branch of a conditional statement is a single statement, use braces in both branches.
 
-[R07] [LNE_R_TWS] No trailing whitespaces at the ends of lines.
+[R05] [LNE_R_TWS] No trailing whitespaces at the ends of lines.
 
-[R08] [LNE_R_EOF] Check for adding lines without a newline at end of file.
-Notes: File should end with '\n' (single newline at the end of file)
+[R06] [LNE_R_EOF] Check for adding lines without a newline at end of file.
+Note: File should end with '\n' (single newline at the end of file)
 
-[R09] In source file, the sequence of the code organization : Copyright File comments Header files Define constant and macros Declare static (private) functions Define exported (public) functions Define static (private) functions Define protected functions.
-Notes: Static (private) function code first, then functions used by other objects in library; API (public) functions at the end
+[R07] In source file, the sequence of the code organization : Copyright, File comments, Header files, Define constant and macros, Declare static (private) functions, Define exported (public) functions, Define static (private) functions, Define protected functions.
+Note: Static (private) function code first, then functions used by other objects in library; API (public) functions at the end
 
 ******** Public API should use 'API' macro - other functions are not visible outside of library
 
-[M07] Separate external public header(API) and internal header(declare protected functions that are not exported but use for many files)
+[M09] Separate external public header(API) and internal header(declare protected functions that are not exported but use for many files)
 
-[M08] External public headers include the Doxygen style for comment. ex) Variable, Function, Struct.
+[M10] External public headers include the Doxygen style for comment. ex) Variable, Function, Struct.
 
-[M09] In function prototypes, include parameter names with their data types and return type.
+[M11] In function prototypes, include parameter names with their data types and return type.
 
-[R10] Macros with multiple statements should be enclosed in a "do -while" block.
+[R08] Macros with multiple statements should be enclosed in a "do -while" block.
 
-[R11] ''#' symbol for macro shall be located at the first column.
+[R09] ''#' symbol for macro shall be located at the first column.
 
-[R12] In macro definition, every expression and the arguments in the expressions shall be enclosed by '(' and ')' for each.
+[R10] In macro definition, every expression and the arguments in the expressions shall be enclosed by '(' and ')' for each.
 
-[R13] Don’t declare both a structure tag and variables or typedefs in the same declaration.
+[R11] Don’t declare both a structure tag and variables or typedefs in the same declaration.
 Note: Avoid use of typedefs for structures/enums unless it's needed (for handles in API etc.)
 
-[R14] Each variable shall be declared in the new line.
+[R12] Each variable shall be declared in the new line.
 Notes: except for counters (like i, j, k, etc.).
 
-[M10] No mixed-case, Use underscores('_') to separate words in a name.
+[M12] No mixed-case, Use underscores('_') to separate words in a name.
 
-[R15] Names of macros defining constants and labels in enums are composed of capital letters, numbers and '_' character.
+[R13] Names of macros defining constants and labels in enums are composed of capital letters, numbers and '_' character.
 
-[R16] Name of functions are Verb + Noun to have a good representation of features.
+[R14] Name of functions are Verb + Noun to have a good representation of features.
 Note: this is rule of thumb except for Public API. Public API has prefix (<library>_<module>_fcn).
 
 --------------------------------------------------------------------------------
@@ -98,8 +98,8 @@ Note: this is rule of thumb except for Public API. Public API has prefix (<libra
 3. Tizen rules that should NOT be followed
 --------------------------------------------------------------------------------
 
-[R17] Local functions whose scope is limited to the current source file have "static" keyword and names started with "__".
-Note: static functions should not include "prefix" but can have arbitrary names (see R16).
+[R15] Local functions whose scope is limited to the current source file have "static" keyword and names started with "__".
+Note: static functions should not include "prefix" but can have arbitrary names (see R14).
 
-[R18] Names of protected(global) functions in internal header are started with '_' character.
-Note: Functions shared between multiple objects can have arbitrary naming (see R16)
+[R16] Names of protected(global) functions in internal header are started with '_' character.
+Note: Functions shared between multiple objects can have arbitrary naming (see R14)