Dev:Coding Conventions

From Synfig Studio :: Documentation
Revision as of 13:20, 16 March 2020 by FirasH (Talk | contribs) (Fix typo)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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 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 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:
    • 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.