Dev:Coding Conventions - Revision history

FirasH: Fix typo

2020-03-16T11:20:55Z

Fix typo

Want at 16:02, 16 March 2017

2017-03-16T16:02:49Z

Genete: /* Formatting */

2010-12-12T18:08:35Z

‎Formatting

Genete: First version

2010-12-12T17:44:25Z

First version

New page

==Introduction==
Here are described the rules or conventions to make the Synfig code better from the point of view of style. The goal is to improve readability and make easier the understanding of the code in any editor and for new potential coders.

The coding rules established by [http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml this link] are good references to follow in case of doubt.

Those rulers are not absolutely mandatory but the Synfig Team reserves the right of reject patches that doesn't follow some minimums.

== Templates ==
In each section (etl, synfig-core, synfig-studio) there is a template file. Use it to create a new file. We use .cpp for implementation and .h for header files.
We usually keep the copyrights of Robert and Adrian when the new file is one version of a similar existing one and should add the copyright of the contributor.

== Names ==

* File names: Filenames should be all lowercase and can include underscores (_). Some further rules may be defined for specific file types (icons, helper files, etc.).
* Type names: Type names start with a capital letter and have a capital letter for each new word, with no underscores.
* Variable names: Variable names are all lowercase, with underscores between words. Class member variables have trailing underscores.
* Function names: --define me--
* Enumerators names: Use capital letters and always use a prefix to identify them all.

== Comments and Documentation ==

* You can use either the // or the /* */ syntax; however, // is much more common. Be consistent with how you comment and what style you use where.
* Please try to document in this order: header file (.h) top description, class descriptions, member descriptions, procedures description. If something else is needed to document, then do it in the implementation file (.cpp)
* When possible document ''before'' the line involved. Documenting in the same line is not recommended.

== Formatting ==

* Use tabs or spaces on the indentation and only spaces on alignment.
* Try to avoid longer lines than 80 characters. If needed break the line using back slash character (\)
* Function implementation:
** Place the returned value in the previous line.
** Place the two curly brackets in the first column and the implementation one indentation right.
* Conditionals, loops, and any thing that needs two curly brackets: Place the curly brackets in the same column and the inside code one indentation right.

@@ Line 1: / Line 1: @@
-{{Title|Coding Convetions}}
+{{Title|Coding Conventions}}
 ==Introduction==
 Here are described the rules or conventions to make the Synfig code better from the point of view of style. The goal is to improve readability and make easier the understanding of the code in any editor and for new potential coders.

← Older revision		Revision as of 16:02, 16 March 2017
Line 1:		Line 1:
		+	{{Title\|Coding Convetions}}
	==Introduction==		==Introduction==
	Here are described the rules or conventions to make the Synfig code better from the point of view of style. The goal is to improve readability and make easier the understanding of the code in any editor and for new potential coders.		Here are described the rules or conventions to make the Synfig code better from the point of view of style. The goal is to improve readability and make easier the understanding of the code in any editor and for new potential coders.

@@ Line 26: / Line 26: @@
 == Formatting ==
-* Use tabs or spaces on the indentation and only spaces on alignment.
+* Use tabs or spaces on the indentation but once selected keep it consistent in all the document. Use only spaces on alignment.
 * Try to avoid longer lines than 80 characters. If needed break the line using back slash character (\)
 * Function implementation: