Updating techbase wiki page according to KF5 policies

[Martin Walch]

On Saturday 07 November 2015 14:41:27 Luigi Toscano wrote:
> >> * Is that wiki page meant to apply to KF5?
> >> * If it shall apply to KF5 is it safe to update it accordingly?
> > 
> > Don't know. Technically the naming is wrong, there's no "kdelibs"
> > in KF5. Maybe you could make a new wiki page instead?
> > 
> >> * Should the coding style for kdelibs from KDE4 be kept around?
> > 
> > Can't hurt to keep it, there might references to it, and some people
> > still write Qt4/kdelibs4 based code (e.g. I do, in my company).
> 
> And also for people that wants to port program, in the foreseeable future. I
> agree that a new page (Frameworks_Coding_Style?) should be created instead.

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

Some questions:
* Spaces after left parentheses/before right parentheses?
* Spaces around binary operators +,-,*,/,%?
* Spaces before/after argument separating commas in function headers/calls?
* Is SIGNAL/SLOT normalization still a thing?
* Put else on the same line as preceding closing brace?
* What about include order?
* Where to put includes (header, implementation)? Use forward declarations?
* Naming of include guards?
* Should include guards go above or below the license text?
* Are there currently any contradictions to the krazy2 style checks?

The last two sections (astyle, emcas, vim) of the kde4libs coding style might
need adjustments depending on changes above.

Regards,
Martin Walch
--