1- # libyang Coding Style
1+ # Contributing to libyang
22
3- This file describes the coding style used in most C files in the libyang
4- library.
3+ First of all, thanks for thinking about contribution to libyang! Not all of us
4+ are C guru, but believe that helping us with docs, tests, helping other users to
5+ solve their issues / answer ther questions or even letting us to know via
6+ [ issue tracker] ( https://github.com/CESNET/libyang/issues ) that something
7+ can be done in a better or just different way is really appreciated.
58
6- ## Basics
9+ If you are willing to contribute, you will definitely have to build and install
10+ libyang first. To do it, please check dependencies and follow build and install
11+ instructions provided in [ README] ( README.md ) .
712
8- - Use space instead of tabs for indentations.
13+ If you have something what you believe should be part of the libyang repository,
14+ add it via [ Github Pull Request mechanism] ( https://help.github.com/articles/about-pull-requests/ ) .
15+ Remember to explain what you wish to add and why. The best approach is to start
16+ with creating an issue and discuss possible approaches there. Pull requests can be
17+ then connected with such issues.
918
10- - There is no strict limit for the line length, However, try to keep lines in a
11- reasonable length (120 characters).
19+ ## Branches
1220
13- - Avoid trailing spaces on lines.
21+ There are 2 main branches in libyang project. The default branch is named ` master ` . It is the
22+ most stable and tested code which you get by default when cloning the Git repository. The
23+ ` devel ` branch introduces new features, API changes or even bugfixes in case ` master ` and
24+ ` devel ` differs significantly at that moment and the fix affects the changed code. There are
25+ some more branches for work-in-progress features and special ` coverity ` branch for submitting
26+ code for the [ analysis in the Coverity tool] ( https://scan.coverity.com/projects/5259 ) usign
27+ [ Travis CI build] ( https://travis-ci.org/CESNET/libyang/branches ) .
1428
15- - Put one blank line between function definitions.
29+ When you create pull request, think carefully about the branch where the patch belongs to.
30+ In most cases (if not all), it is the ` devel ` branch.
31+
32+ ## Issue Ticketing
33+
34+ All the communication with the developers is done via [ issue tracker] ( https://github.com/CESNET/libyang/issues ) .
35+ You can send us an email, but in case you will ask a question we would think that someone else
36+ could ask in future, our answer will be just ** use the issue tracker** . Private emails are not visible
37+ for others and we don't want to answer the same questions.
38+
39+ So when you are goingto submit a new issue, ** please:**
40+ * check that the issue you are having is not already solved in the devel branch,
41+ * go through the present issues (in case of question, it can be already a closed issue) in the tracker,
42+ * give it as descriptive title as possible,
43+ * separate topics - solving multiple issues in one ticket hides the issues from others,
44+ * provide as much relevant information as possible (versions, logs, input data, etc.).
1645
46+ ## libyang Coding Style
47+
48+ When you are going to contribute C code, please follow these coding style guidelines.
49+
50+ ### Basics
51+
52+ - Use space instead of tabs for indentations.
53+ - There is no strict limit for the line length, However, try to keep lines in a
54+ reasonable length (120 characters).
55+ - Avoid trailing spaces on lines.
56+ - Put one blank line between function definitions.
1757- Don't mix declarations and code within a block. Similarly, don't use
1858 declarations in iteration statements.
1959
20- ## Naming
60+ ### Naming
2161
2262Use underscores to separate words in an identifier: ` multi_word_name ` .
2363
@@ -27,7 +67,7 @@ members of enumerations.
2767Do not use names that begin with ` _ ` . If you need a name for "internal use
2868only", use ` __ ` as a suffix instead of a prefix.
2969
30- ## Comments
70+ ### Comments
3171
3272Avoid ` // ` comments. Use ` /* ... */ ` comments, write block comments with the
3373leading asterisk on each line. You may put the ` /* ` and ` */ ` on the same line as
@@ -39,7 +79,7 @@ comment text if you prefer.
3979 */
4080```
4181
42- ## Functions
82+ ### Functions
4383
4484Put the return type, function name, and the braces that surround the function's
4585code on separate lines, all starting in column 0.
@@ -80,15 +120,15 @@ and ignore a null pointer argument. Code that calls such a function (including
80120the C standard library function ` free() ` ) should omit a null-pointer check. We
81121find that this usually makes code easier to read.
82122
83- ### Function Prototypes
123+ #### Function Prototypes
84124
85125Put the return type and function name on the same line in a function prototype:
86126
87127``` c
88128static const struct int foo (int arg);
89129```
90130
91- ## Statements
131+ ### Statements
92132
93133- Indent each level of code with 4 spaces.
94134- Put single space between `if`, `while`, `for`, etc. statements and the
@@ -121,7 +161,7 @@ default:
121161- Do not put gratuitous parentheses around the expression in a return statement,
122162that is, write ` return 0; ` and not ` return(0); `
123163
124- ## Types
164+ ### Types
125165
126166Use typedefs sparingly. Code is clearer if the actual type is visible at the
127167point of declaration. Do not, in general, declare a typedef for a struct, union,
@@ -135,7 +175,7 @@ integer types. Use the `PRId<N>`, `PRIu<N>`, and `PRIx<N>` macros from
135175Pointer declarators bind to the variable name, not the type name. Write
136176` int *x ` , not ` int* x ` and definitely not ` int * x ` .
137177
138- ## Expresions
178+ ### Expresions
139179
140180Put one space on each side of infix binary and ternary operators:
141181
0 commit comments