[Kde-pim] coding-style for KDEPIM

[Ingo Klöcker]

On Thursday 07 March 2013, Allen Winter wrote:
> On Thursday 07 March 2013 04:19:32 PM John Layt wrote:
> > 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/Korganiz
> > > er
> > > 
> > > 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 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.
> > 
> > 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
> > 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.
> 
> Gee... I disagree with just about all of this.

Can you be a bit more specific? What exactly do you disagree with and 
what do you not disagree with.


> Back to a complete mess we go.

This statement is neither helpful nor constructive. Where do you see a 
mess? What do you propose to avoid the mess?


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20130308/d8f9cbcf/attachment.sig>
-------------- next part --------------
_______________________________________________
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/