On 15 Mar 2013, at 2:03 PM, Alberto Mardegan wrote:
Not much relevant here, but just in the unlikely event that everyone
will confess to like this style more, here's what I use in my own projects:
MyClass::MyClass(...):
GvbWidget(parent),
m_background()
{
I do that too.
On sexta-feira, 15 de março de 2013 04.16.46, Axel Waggershauser wrote:
With the trailing whitespace issue pretty much fixed, the next step is
eliminating leading tabs. A few questions about that:
1) If in doubt, is it generally fair to assume that whatever
QtCreator's CTRL+i in the default
On Fri, Mar 15, 2013 at 8:11 AM, Thiago Macieira
thiago.macie...@intel.com wrote:
2 c) if vs. while lines seem obviously inconsistent
if (test == true
1 == 0) // 8 spaces == 4 relative to the '('
This is a special case because of a {
If you write:
if (test == true
On Fri, Mar 15, 2013 at 12:11:00AM -0700, Thiago Macieira wrote:
On sexta-feira, 15 de março de 2013 04.16.46, Axel Waggershauser wrote:
2 a) I found a place with 8 spaces indent but QtCreator would indent
it further to 12 so that the following 'Q' aligns with the 's'
On Fri, Mar 15, 2013 at 04:16:46AM +0100, Axel Waggershauser wrote:
3) I came across a macro that had a semicolon at the end. I think this
is sub-optimal. Without special support in the IDE (like for the
Q_OBJECT macro) this leads to the following auto indented code:
On Fri, Mar 15, 2013 at 12:49:55PM +0100, Axel Waggershauser wrote:
On Fri, Mar 15, 2013 at 8:11 AM, Thiago Macieira thiago.macie...@intel.com
wrote:
4) What about consistent placement of the ',' in class member
initialization lists? I've seen
: GvbWidget(parent),
On 03/15/2013 02:51 PM, Oswald Buddenhagen wrote:
On Fri, Mar 15, 2013 at 12:49:55PM +0100, Axel Waggershauser wrote:
On Fri, Mar 15, 2013 at 8:11 AM, Thiago Macieira thiago.macie...@intel.com
wrote:
4) What about consistent placement of the ',' in class member
initialization lists? I've
With the trailing whitespace issue pretty much fixed, the next step is
eliminating leading tabs. A few questions about that:
1) If in doubt, is it generally fair to assume that whatever
QtCreator's CTRL+i in the default built-in Qt coding style does, is
the way to go?
2) Especially continuation
On Wed, Mar 13, 2013 at 01:38:31AM +0100, Axel Waggershauser wrote:
I'd say in terms of Lars's worries about having automatic checks in
place before attacking whitespace issues, there should not be any
objection against fixing at least those 4 issues immediately.
One might ask, though, if it
On Wed, Mar 13, 2013 at 10:30 AM, Oswald Buddenhagen
oswald.buddenha...@digia.com wrote:
On Wed, Mar 13, 2013 at 01:38:31AM +0100, Axel Waggershauser wrote:
I'd say in terms of Lars's worries about having automatic checks in
place before attacking whitespace issues, there should not be any
On Wed, Mar 13, 2013 at 03:57:01PM +0100, Axel Waggershauser wrote:
On Wed, Mar 13, 2013 at 10:30 AM, Oswald Buddenhagen
oswald.buddenha...@digia.com wrote:
actual enforcement was lars' request.
but this clearly requires a very low false report rate to be accepted.
I see. Regarding false
On Tue, Mar 12, 2013 at 04:35:59AM +0100, Axel Waggershauser wrote:
So to fix whitespace (according to
http://qt-project.org/wiki/Qt_Coding_Style) one has to come up with
whitespace-only patches. I have a couple of questions regarding those:
1. Is something like the above patch welcome at
3. How to best split up patches from that category? e.g. fixing all
if(...){ - if (...) { occurrences in qtbase would be a rather
large patch (I have it half done)
a) split that up based on manageable subdirectories?
yes, and that only for easy recovery from merge conflicts (which you
Axel sayeth:
snip, whitespace-only changes for consistency to
coding standard
+1 YAY, Axel!
This is a personal wish by me -- consistency. Including for whitespace.
I find it astounding the legacy-code-bases that essentially decide that
they cannot be improved -- no such patches are
On Tue, Mar 12, 2013 at 01:34:54PM +0100, Axel Waggershauser wrote:
I thought splitting by type first and potentially by directory second
if it is too big still, would be best because it reduces the burden on
the reviewer: only one type of change should be easier to skim over
the downside of
On Tue, Mar 12, 2013 at 2:11 PM, Oswald Buddenhagen
oswald.buddenha...@digia.com wrote:
On Tue, Mar 12, 2013 at 01:34:54PM +0100, Axel Waggershauser wrote:
I thought splitting by type first and potentially by directory second
if it is too big still, would be best because it reduces the burden
On Tue, Mar 12, 2013 at 03:14:43PM +0100, Axel Waggershauser wrote:
On Tue, Mar 12, 2013 at 2:11 PM, Oswald Buddenhagen
oswald.buddenha...@digia.com wrote:
if the burden on the reviewer is too big, then you didn't split it up
according to directories/modules sufficiently well.
What would
2013/3/12 Oswald Buddenhagen oswald.buddenha...@digia.com:
somebody attempted this just a few days ago, but gave up when the scope
of the undertaking became clear. i can't find the change now ...
https://codereview.qt-project.org/#change,48150
I indeed gave up, or at least I was trying to
On Tue, Mar 12, 2013 at 5:32 PM, Oswald Buddenhagen
oswald.buddenha...@digia.com wrote:
it went to the trash because the idea was not liked back then. the winds
appear to have changed meanwhile.
That is a pitty. Given, that I already spent a bunch of hours looking
into this, I hope you are
19 matches
Mail list logo
