kdelibs coding style

[Maks Orlovich]

> Thank you for the explanation. Now I can understand your point of view.
>
> I just want to ask you: how is the indentation style any more a deterring
> factor than all of the other policies we have now? A couple of examples:

>
> 1) the naming style:
> 	KClassName::camelCaseFunctionName
> 	KClassName::UpperCasedConstant
>
> 2) the namespacing style:
> 	classes in kdecore and kdeui aren't namespaced
> 	all other libraries are namespaced

The difference is that the naming policies affect the library's users. #2 
isn't actually true, by the way. 

>
> 3) the coding style:
> 	d-pointers

They have a clear technical benefit, and are the current "best practice" for 
permitting addition of fields.

> 	Private or KClassPrivate (we haven't decided that yet)

I think that one is a bad thing to have policy on, too.

> 	virtual hooks

See d-pointer --- and note the discussion about removing them thanks to Qt's 
functionality. 

> 	no private member variables

This one is borderline. There are cases where private variables may be a 
complete pain in the butt to remove, but I can think of only one time this 
problem actually happened, and in most cases it seems like adding extra 
indirections all over the place.

>
> 4) the binary compatibility guidelines
> 	no removing existing functions
> 	no reordering virtual functions
> 	no adding new virtual functions in non-leaf classes

Following them brings clear benefits to the users. 

> If I were to rank the indentation guideline, I'd put it below all those 4
> above in a list of things that new contributors would have trouble
> adapting with.

Sure, but I would say nearly all of these above have clear, unambiguous 
benefits. Having someone change where the braces are in Keramik or how many 
spaces khtml/ecma is indented with doesn't. 

-Maks