Plexy Hacking Guideline¶

Coding Style¶

• Formatting rules:
  Use 4 spaces to indent and do not use tabs.
  The length of a line should be 80 chars wide. When the lines are longer than 80 start a new line.
  Put spaces between operators and arguments.
  Put spaces between brackets and arguments of functions.
  For pointer and reference variable declarations, put a space between the type and the or & and no space before the variable name.
  For if, else, while and similar statements put the brackets on the same line as the statement.
  Function and class definitions have their brackets on separate lines.
  For class, variable, function names, separate multiple words by upper-casing the words preceded by other words.
  Make sure that source file hasn't useless blank spaces.

• Class Names:
  Class names start with an upper-case letter - example : class Cookie {};

• Variable Names:
  Use Variables that makes sense and has logical sense.
  Variable names start with a lower-case letter.
  Member variables of a class start with "m" followed by an upper-case letter.

• Function Names:
  Function names start with a lower-case letter.
  Use functions that make sense and have logical sense - example : fooBar ()

• Header Formats:
  General formatting rules apply.
  Access modifiers are indented.
  Put curly brackets of class definitions on its own line.
  Double inclusion protection defines are all upper case letters and are composed of the namespace (if available), the classname and a H suffix separated by underscores.
  Inside a namespace there is no indentation.

• Pre-processor commands:

• Comment styles:
  Each public function must have a Doxygen compatible comment in the header.

• Misc:
  Use true or false to Booleans and 0 for null pointers.

• Automating Indentation:
  Use GNU indent to batch indent source files. You may use these options "indent -nprs -nbap -bap -bc -bad -bap -bbb -br -lp -l80 -nut -i4 -nce". But we don't
  recommend the use of this tool, as we have seen it has bugs which results in inconstant styles. So the best option is to make sure you follow the rules when you
  code, and correct when you spot a code segment that breaks it.

GIT commit Guide ¶

• How to Apply : Email one of the core members or ask about it on the mailing list.

• Before you commit : Make sure the code matches the hacking guidelines, and it compiles with a known compiler.

• What you shouldn't commit : temporary files and hidden files. This can happen when you try to import or add a new directory.
  Then also do not commit copyrighted images or similar.
  Since PlexyDesk is a LGPL project, please attach a copyright notice for each binary file you will commit to the repository.

• When and When not to commit : When there is a freeze announced, please do not commit. This can mess up the process. If the commit is a must,
  then talk about it on the mailing list or IRC before doing so.

NOTE: Some parts taken from KDE PIM Hacking Guide