Updating techbase wiki page according to KF5 policies

[Alex Merry]

On 2015-11-14 01:21, Martin Walch wrote:
> Alright, so I have created a stub at
> 
> https://techbase.kde.org/Policies/Frameworks_Coding_Style
> 
> Probably most other things have remained unchanged and can be copied 
> over from
> 
> https://techbase.kde.org/Policies/Kdelibs_Coding_Style
> 
> So, if anything has changed, please give me a hint now (I do not know 
> it,
> because I have not written any real code for the KF5 libs so far). The 
> kde4libs
> coding style summarized is:
> 
> -------------------------------------
> Indentation:
> * 4 spaces
> * No tabs
> 
> Variable declaration:
> * Each declaration on its own line
> * Use camelCase
> * Avoid abbreviations
> * Useful names, no short names except obvious counters and temporary 
> variables
> * Variables and functions start with lower case letter
> 
> Whitespace
> * Group statements with blank lines
> * Use only single empty lines
> * Follow each keyword with exactly one space
> * For pointers and references exactly one space before '*' and '&', 
> none after
> * No space after cast
> 
> Braces
> * Opening braces of control flow statements on the same line
> * For classes, structs, and namespaces they go on the start of the next 
> line
> * Use braces even for single line bodies
> 
> Switch statements
> * Put case on the same column as switch
> 
> Line length
> * Try to stay below 100 characters, break over several lines if 
> necessary
> 
> Qt includes
> * For Qt #includes omit the module name and only use the class name.

These are all still applicable.

> -------------------------------------
> 
> Some questions:
> * Spaces after left parentheses/before right parentheses?

No.

> * Spaces around binary operators +,-,*,/,%?

Yes.

> * Spaces before/after argument separating commas in function 
> headers/calls?

After only.

> * Is SIGNAL/SLOT normalization still a thing?

Still useful for efficiency when you are using string descriptors, but 
obviously irrelevant if you use the function-pointer syntax [eg: 
connect(target, &OtherClass::someSignal, this, &MyClass::someSlot)].

> * Put else on the same line as preceding closing brace?

Yes.

> * What about include order?

In a cpp file, matching header file (if applicable) goes first. eg: in 
kaboutdata.cpp, the first include is kaboutdata.h. This helps catch when 
you forget to put includes or forward declarations in the header.

Then headers from same framework.

Then headers from other frameworks.

Then Qt headers.

Then other headers.

Each section sorted alphabetically.

> * Where to put includes (header, implementation)? Use forward 
> declarations?

Forward declarations where possible, includes in implementation 
preferred over putting them in the header.

> * Naming of include guards?

Based on how you would include it. eg: if you would include it as 
<KAboutData>, use KABOUTDATA_H. If you would include it as <KIO/Job>, 
use KIO_JOB_H.

> * Should include guards go above or below the license text?

Below.

> * Are there currently any contradictions to the krazy2 style checks?

Not sure, sorry.

Note that all rules can be broken if, in a particular situation, doing 
so helps readability of the code.

Alex