[prev in list] [next in list] [prev in thread] [next in thread] 

List:       calligra-devel
Subject:    Re: Re: [Kexi-devel] RFC: plan for starting the Qt5/KF5 port
From:       Dmitry Kazakov <dimula73 () gmail ! com>
Date:       2015-02-25 14:28:46
Message-ID: CAEkBSfXde2hDhGri-hzZ4wc6QeXNxcrntKJJzPp8X+pR4sT2Mg () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hi!

My 2 cents :)

1) astyle

Last time astyle was applied to Krita code (something around 2010-2011, it
was applied partially?) I really didn't like the result. At least the thing
it did with braces and indentation. I guess we just need to choose really
carefully what to change and what not. E.g. one-line-return-if-error ifs
might not have braces. That is I don't agree that the policy statement "Use
curly braces even when the body of a conditional statement contains only
one line" should be followed blindly.

For the rest, e.g. include style, tab vs spaces, lines with trailing
whitespace I'm ok with fixing it automatically.

2) If astyle applied, it must be applied to master-only. Under no
circumstances to calligra/2.9. Without being able to use 'git blame' it'll
be tough to fix many kinds of bugs and do bisecting.

3) #pragma once

To tell you the truth I cannot remember a single case of facing a problem
with include guards for last several years. Why should we bother about any
non-standard compiler extensions then? My emacs scripts handle it quite
perfectly, I am pretty sure that QtCreator can also crack it. I just don't
understand the reasoning. Does MacOS compilers support it well enough?





On Wed, Feb 25, 2015 at 1:18 PM, Boudewijn Rempt <boud@valdyas.org> wrote:

> On Wed, 25 Feb 2015, C. Boemann wrote:
>
>  On Wednesday 25 February 2015 10:01:16 Boudewijn Rempt wrote:
>>
>>> > Applying full astyle is IMHO not OK, and even against efforts of
>>> > everyone who keeps eye on proper coding style while doing code
>>> > reviews.
>>>
>>> Sorry, our current code base is a mess. I don't care about kexi, and I
>>> won't touch kexi. I won't touch any library except for pigment. But the
>>> mess we have with bracket placing, include styles, spaces around function
>>> arguments, initializer lists... It just needs cleaning up.
>>>
>> I'm not against cleaning up coding style, but any such commit should
>> follow what we are practicing already, and not some half broken astyle. I
>> have no idea what astyle does and doesn't do, but i will not accept commits
>> away from our qt/kde style.
>>
>> so show me that it doesn't mess up please
>>
>>
> Check David's notes in kde-dev-scripts, please. That's what I was
> referring to. And sure I'll be careful.
>
> Boudewijn
>
> _______________________________________________
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>



-- 
Dmitry Kazakov

[Attachment #5 (text/html)]

<div dir="ltr"><div><div><div><div><div><div>Hi!<br><br></div>My 2 cents \
:)<br><br></div>1) astyle<br><br></div>Last time astyle was applied to Krita code \
(something around 2010-2011, it was applied partially?) I really didn&#39;t like the \
result. At least the thing it did with braces and indentation. I guess we just need \
to choose really carefully what to change and what not. E.g. one-line-return-if-error \
ifs might not have braces. That is I don&#39;t agree that the policy statement \
&quot;Use curly braces even when the body of a conditional statement contains only \
one line&quot; should be followed blindly. <br><br></div>For the rest, e.g. include \
style, tab vs spaces, lines with trailing whitespace I&#39;m ok with fixing it \
automatically.<br><br></div><div>2) If astyle applied, it must be applied to \
master-only. Under no circumstances to calligra/2.9. Without being able to use \
&#39;git blame&#39; it&#39;ll be tough to fix many kinds of bugs and do \
bisecting.<br></div><div><br></div>3) #pragma once<br><br></div>To tell you the truth \
I cannot remember a single case of facing a problem with include guards for last \
several years. Why should we bother about any non-standard compiler extensions then? \
My emacs scripts handle it quite perfectly, I am pretty sure that QtCreator can also \
crack it. I just don&#39;t understand the reasoning. Does MacOS compilers support it \
well enough?<br><div><br><div><div><div><br><br><br></div></div></div></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 1:18 PM, \
Boudewijn Rempt <span dir="ltr">&lt;<a href="mailto:boud@valdyas.org" \
target="_blank">boud@valdyas.org</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On Wed, 25 Feb 2015, C. Boemann wrote:<br> \
<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> On Wednesday 25 February 2015 10:01:16 Boudewijn Rempt \
wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> &gt; Applying full astyle is IMHO not OK, and even \
against efforts of<br> &gt; everyone who keeps eye on proper coding style while doing \
code<br> &gt; reviews.<br>
<br>
Sorry, our current code base is a mess. I don&#39;t care about kexi, and I won&#39;t \
touch kexi. I won&#39;t touch any library except for pigment. But the mess we have \
with bracket placing, include styles, spaces around function arguments, initializer \
lists... It just needs cleaning up.<br> </blockquote>
I&#39;m not against cleaning up coding style, but any such commit should follow what \
we are practicing already, and not some half broken astyle. I have no idea what \
astyle does and doesn&#39;t do, but i will not accept commits away from our qt/kde \
style.<br> <br>
so show me that it doesn&#39;t mess up please<br>
<br>
</blockquote>
<br></span>
Check David&#39;s notes in kde-dev-scripts, please. That&#39;s what I was referring \
to. And sure I&#39;ll be careful.<span class="HOEnZb"><font color="#888888"><br> <br>
Boudewijn</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org" \
target="_blank">calligra-devel@kde.org</a><br> <a \
href="https://mail.kde.org/mailman/listinfo/calligra-devel" \
target="_blank">https://mail.kde.org/mailman/<u></u>listinfo/calligra-devel</a><br> \
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div \
class="gmail_signature">Dmitry Kazakov</div> </div>


[Attachment #6 (text/plain)]

_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic