[Kde-pim] coding-style for KDEPIM

[guy-kde]

Am 07.03.2013 17:19, schrieb John Layt:
> On 7 March 2013 15:26, Allen Winter <winter at kde.org> wrote:
>> On Thursday 07 March 2013 11:26:43 AM Guy Maurel wrote:
>>> As discussed at the KDEPIM meeting, Berlin, 3 March 2013, all the 
>>> files of
>>> KDEPIM will be reviewed to follow the coding style. This will be 
>>> done over a
>>> long time, directory after directory, for each of the rules.
>>> 
>>> I opened a new URL for that:
>>>    http://techbase.kde.org/Policies/Kdepim_Coding_Style
>>> 
>>> This is still in construction.
>>> Please, have a look to my proposal and comment it.
>>> Any suggestions, fixes are welcome.
>>> 
>> Guy,
>> We already have a coding style page at
>> http://community.kde.org/KDE_PIM/Development/CodingStyle/Korganizer
>> 
>> So you can copy that in and make changes as needed.
>> Then remove it.
>> 
>> I do object to the 4 space indent level. I like 2 better.
>> especially if we keep to a 100-char line length limit.
>> 
>> I need to change Krazy checker accordingly.
>> 
>> Why can't we do one big astyle change all in one go?
> 
> To fill in a few details, the decision was taken to get our style as
> close to kdelibs and Qt as possible to remove the barrier for new
right.
I spoke with David. He shows me the kdelibs-Rules. I make also a 
reference to it.

> users and contributors from the Qt world and kdelibs.  It's also going
> to be a requirement for KDE Frameworks 5 inclusion where we want to
> move many of the libraries.  Personally, having to remember all the
> small style differences between Qt, kdelibs and kdepimlibs is annoying
> and frustrating and creates rework for me.
This should be less in the future.

> It was also decided that changing style will only be done with the
> agreement of each library's maintainer, for example David can opt not
> to have the KAlarm libraries converted.  However it is preferred to
> move to kdelibs style.
> 
> Finally, there was some mention that it can't be fully-automated as
this is the biggest problem!

> there are many sections of code where it would be dangerous, such as
> over-the-wire protocols, so all changes need to be checked and tested
> before committing.
I think I do those parts which don't make any trouble. This work is big
enought for today.

The next steps are to find some methods for the complicated cases and
discuss about.
-- 
guy-kde
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/