org
Subject: Re: [Development] Qt Coding Guidelines
On 16 March 2016 at 21:43, Knoll Lars
mailto:lars.kn...@theqtcompany.com>> wrote:
Good initiative. I think this is the right idea. Let's put the coding
guidelines into .qdoc files after having a decision on the ML.
We should actually
On Friday 18 March 2016 15:37:40 André Somers wrote:
> Op 18/03/2016 om 09:24 schreef Rutledge Shawn:
> > Forcing it on everyone that way will be controversial, because there
> > is still some leeway in formatting, whereas automation would remove
> > any chance of personal preference, and probably
Thiago Macieira said:
> We have a qdoc generator. We don't have a markdown generator.
>
> More importantly, we know how to write qdoc syntax.
There is also an "eat our own dog-food" argument somewhere here: we ask
developers to document their code in qdoc, so we should be happy to use
it ourselves
> On 16 Mar 2016, at 22:43, Knoll Lars wrote:
>
> We should actually consider having a section about contributing to Qt in our
> documentation. Coding guidelines would fit nicely into that. But I think the
> .qdoc files should rather live in qtdoc instead of qtbase as most of the
> overview d
On Friday, March 18, 2016 10:46:41 AM Koehne Kai wrote:
> > -Original Message-
> > From: Development [mailto:development-
> > [...]
> > It remains that this document is expected to be quite stable, so there
> > would be some sense to having a stable URL to which we routinely copy the
> > ne
On 16 mars 2016, at 16:14, Koehne Kai wrote:
> Hi there,
>
> We have had quite some discussions about the use of C++11 features and right
> API in the past on this mailing list - but if there has been a consensus
> (which is sometimes hard to find out), it was often buried pretty deep in the
Op 18/03/2016 om 18:54 schreef Allan Sandfeld Jensen:
On Friday 18 March 2016, André Somers wrote:
Op 18/03/2016 om 09:24 schreef Rutledge Shawn:
Forcing it on everyone that way will be controversial, because there
is still some leeway in formatting, whereas automation would remove
any chance
Op 18/03/2016 om 09:24 schreef Rutledge Shawn:
Forcing it on everyone that way will be controversial, because there
is still some leeway in formatting, whereas automation would remove
any chance of personal preference, and probably screw up in some
cases. But we could at least start by addin
Hi there,
We have had quite some discussions about the use of C++11 features and right
API in the past on this mailing list - but if there has been a consensus (which
is sometimes hard to find out), it was often buried pretty deep in the mailing
thread. IMO it would be good to make decisions mo
Op 16/03/2016 om 16:14 schreef Koehne Kai:
Hi there,
We have had quite some discussions about the use of C++11 features and right
API in the past on this mailing list - but if there has been a consensus (which
is sometimes hard to find out), it was often buried pretty deep in the mailing
th
On 18/03/16 16:44, "Development on behalf of Thiago Macieira"
wrote:
>On sexta-feira, 18 de março de 2016 10:46:41 PDT Koehne Kai wrote:
>> > It remains that this document is expected to be quite stable, so there
>> > would be some sense to having a stable URL to which we routinely copy the
>>
> -Original Message-
> From: sergio On Behalf Of Sergio Martins
> Sent: Thursday, March 17, 2016 3:16 PM
> To: Koehne Kai
> Cc: development@qt-project.org
> Subject: Re: [Development] Qt Coding Guidelines
>
> On Thursday, March 17, 2016 02:30:03 PM Koeh
On Friday 18 March 2016, André Somers wrote:
> Op 18/03/2016 om 09:24 schreef Rutledge Shawn:
> > Forcing it on everyone that way will be controversial, because there
> > is still some leeway in formatting, whereas automation would remove
> > any chance of personal preference, and probably screw up
> On Mar 16, 2016, at 20:33, André Somers wrote:
>
>
>
> Op 16/03/2016 om 16:14 schreef Koehne Kai:
>> Hi there,
>>
>> We have had quite some discussions about the use of C++11 features and right
>> API in the past on this mailing list - but if there has been a consensus
>> (which is someti
On 3/17/16, 6:24 AM, "Development on behalf of Mathias Hasselmann"
wrote:
>
>Actually having the Qt code style as public document proved to be
>extremely useful in the past to quickly shutdown this inevitable and
>highly annoying bike shed discussion about code style that happens at
>the start of
On Thursday 17 of March 2016 12:29:46 André Somers wrote:
> Op 17/03/2016 om 11:24 schreef Mathias Hasselmann:
> > Am 17.03.2016 um 10:01 schrieb Sorvig Morten:
> >> How about treating the coding guidelines as \internal documentation?
> >> We could then at some point build and publish it together w
I’m all for an automated solution for code formatting, so we can remove
discussions/comments about wrongly placed braces or spaces from code review and
can rather focus more on the content. But there will be still a need for some
coding guidelines in other places (like auto usage, foreach and ma
Op 16/03/2016 om 20:47 schreef Ziller Eike:
On Mar 16, 2016, at 20:33, André Somers wrote:
Op 16/03/2016 om 16:14 schreef Koehne Kai:
Hi there,
We have had quite some discussions about the use of C++11 features and right
API in the past on this mailing list - but if there has been a cons
On Friday 18 of March 2016 09:13:13 Knoll Lars wrote:
> I’m all for an automated solution for code formatting, so we can remove
> discussions/comments about wrongly placed braces or spaces from code review
> and can rather focus more on the content. But there will be still a need
> for some coding
On quinta-feira, 17 de março de 2016 15:57:23 PDT Koehne Kai wrote:
> > If I recommend the Qt coding style to a customer, he'll come back and say
> > "How do I open this?".
>
> How do they open a .qdoc file? They probably don't, but browse the
> generated .html documentation. The same can be done
On 17/03/16 00:14, "Development on behalf of Thiago Macieira"
wrote:
>On quarta-feira, 16 de março de 2016 21:43:00 PDT Knoll Lars wrote:
>> Good initiative. I think this is the right idea. Let's put the coding
>> guidelines into .qdoc files after having a decision on the ML.
>
>As I said, the
Op 17/03/2016 om 11:24 schreef Mathias Hasselmann:
Am 17.03.2016 um 10:01 schrieb Sorvig Morten:
How about treating the coding guidelines as \internal documentation?
We could then at some point build and publish it together with the
rest of the \internal's. (suitably separated from the publi
Am 17.03.2016 um 10:01 schrieb Sorvig Morten:
How about treating the coding guidelines as \internal documentation?
We could then at some point build and publish it together with the
rest of the \internal's. (suitably separated from the public user
documentation)
Actually having the Qt code st
On 16 March 2016 at 21:43, Knoll Lars wrote:
> Good initiative. I think this is the right idea. Let's put the coding
> guidelines into .qdoc files after having a decision on the ML.
>
> We should actually consider having a section about contributing to Qt in
> our documentation. Coding guidelines
17.03.2016, 20:23, "Giuseppe D'Angelo" :
> Il 17/03/2016 18:09, Welbourne Edward ha scritto:
>> There is also an "eat our own dog-food" argument somewhere here: we ask
>> developers to document their code in qdoc, so we should be happy to use
>> it ourselves, even for not-quite-code things.
>
Il 17/03/2016 18:09, Welbourne Edward ha scritto:
There is also an "eat our own dog-food" argument somewhere here: we ask
developers to document their code in qdoc, so we should be happy to use
it ourselves, even for not-quite-code things.
The question is, can/should we get the HTML output of t
On Thu, Mar 17, 2016 at 3:24 AM, Mathias Hasselmann
wrote:
>
>
> Am 17.03.2016 um 10:01 schrieb Sorvig Morten:
>>
>> How about treating the coding guidelines as \internal documentation?
>> We could then at some point build and publish it together with the
>> rest of the \internal's. (suitably sepa
On 18/03/16 16:03, "Development on behalf of Marc Mutz"
wrote:
>On Friday 18 March 2016 15:37:40 André Somers wrote:
>> Op 18/03/2016 om 09:24 schreef Rutledge Shawn:
>> > Forcing it on everyone that way will be controversial, because there
>> > is still some leeway in formatting, whereas autom
Good initiative. I think this is the right idea. Let's put the coding
guidelines into .qdoc files after having a decision on the ML.
We should actually consider having a section about contributing to Qt in our
documentation. Coding guidelines would fit nicely into that. But I think the
.qdoc f
On Thursday 17 March 2016 08:37:38 Knoll Lars wrote:
> On 17/03/16 00:14, "Development on behalf of Thiago Macieira" wrote:
> >On quarta-feira, 16 de março de 2016 21:43:00 PDT Knoll Lars wrote:
> >> Good initiative. I think this is the right idea. Let's put the coding
> >> guidelines into .qdoc f
On Thursday, March 17, 2016 02:30:03 PM Koehne Kai wrote:
(snip)
> Completely orthogonal to this is though in which format the documents
> are. You're specifically mentioning .qdoc, but I assume it wouldn't really
> matter if it's Markdown (from the 'reusability' perspective)?
If we keep these d
On quarta-feira, 16 de março de 2016 20:56:42 PDT André Somers wrote:
> Doesn't that lead to having the discussion twice: first once in the ML,
> then again in the MR for the change?
The ML is the ultimate decider, so if we had consensus on the list, that's
that. The discussion in the change may
On Thursday, March 17, 2016 11:24:10 AM Mathias Hasselmann wrote:
> Am 17.03.2016 um 10:01 schrieb Sorvig Morten:
> > How about treating the coding guidelines as \internal documentation?
> > We could then at some point build and publish it together with the
> > rest of the \internal's. (suitably se
On quarta-feira, 16 de março de 2016 21:43:00 PDT Knoll Lars wrote:
> Good initiative. I think this is the right idea. Let's put the coding
> guidelines into .qdoc files after having a decision on the ML.
As I said, there is already a change by Marc that adds this file (it was an .md
instead of
On quarta-feira, 16 de março de 2016 15:14:24 PDT Koehne Kai wrote:
> Hi there,
>
> We have had quite some discussions about the use of C++11 features and right
> API in the past on this mailing list - but if there has been a consensus
> (which is sometimes hard to find out), it was often buried p
Kai Koehne said:
> I've been contemplating whether we should instead use some more
> formalized decision process. We could have a document uploaded in git,
> and every change needs to be reviewed and approved by Lars.
This sounds like an eminently sensible way to document a consensus: we
can have
+1 to this idea.
-mandeep
On Wed, Mar 16, 2016 at 8:14 AM, Koehne Kai wrote:
> Hi there,
>
> We have had quite some discussions about the use of C++11 features and right
> API in the past on this mailing list - but if there has been a consensus
> (which is sometimes hard to find out), it was
> -Original Message-
> From: Development [mailto:development-
> bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of
> Sergio Martins
> Sent: Thursday, March 17, 2016 1:15 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt Coding Guidel
On sexta-feira, 18 de março de 2016 10:46:41 PDT Koehne Kai wrote:
> > It remains that this document is expected to be quite stable, so there
> > would be some sense to having a stable URL to which we routinely copy the
> > new version once a change to the source has been accepted. The effort
> >
Il 17/03/2016 18:58, Konstantin Tokarev ha scritto:
What's wrong with reading them as plain text?
What's the point at using a markup format then?
(And cf. the proposal of having the guidelines available somewhere
easily, to point people to them.)
Cheers,
--
Giuseppe D'Angelo | giuseppe.dang
Il 16/03/2016 16:14, Koehne Kai ha scritto:
We already have the coding conventions
page:https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at
keeping it up to date - and one reason is IMO that, given that it's a wiki
everybody can edit, people in a twist of irony stay away
+1
Il 16/mar/2016 16:14, "Koehne Kai" ha scritto:
> Hi there,
>
> We have had quite some discussions about the use of C++11 features and
> right API in the past on this mailing list - but if there has been a
> consensus (which is sometimes hard to find out), it was often buried pretty
> deep in t
(snip)
On Friday, March 18, 2016 08:48:52 AM Jedrzej Nowacki wrote:
> So I think, that we should not discuss what is better qdoc or md. The real
> discussion is about tooling, what is the best tool to sanitize Qt code.
This thread is derailing.
Kai wants to move a few wiki documents to git, ther
> On 18 Mar 2016, at 08:48, Jędrzej Nowacki
> wrote:
>
> So I think, that we should not discuss what is better qdoc or md. The real
> discussion is about tooling, what is the best tool to sanitize Qt code. We
> need something that:
> 1. Can work as a sanity bot
> 2. Can re-format the code by
On Friday 18 March 2016 17:05:37 Knoll Lars wrote:
> On 18/03/16 16:03, "Development on behalf of Marc Mutz" wrote:
> >On Friday 18 March 2016 15:37:40 André Somers wrote:
> >> Op 18/03/2016 om 09:24 schreef Rutledge Shawn:
> >> > Forcing it on everyone that way will be controversial, because ther
> -Original Message-
> From: Development [mailto:development-
> [...]
> It remains that this document is expected to be quite stable, so there would
> be some sense to having a stable URL to which we routinely copy the new
> version once a change to the source has been accepted. The effo
Giuseppe D'Angelo:
>>> The question is, can/should we get the HTML output of these documents
>>> published somewhere, for ease of access?
All the HTML generated from QDoc in all of our code should be visible in
some public way. This would just be one more page of that.
>>> Do they need their own
On Friday 18 March 2016 23:45:22 Marc Mutz wrote:
> On Friday 18 March 2016 17:05:37 Knoll Lars wrote:
> > On 18/03/16 16:03, "Development on behalf of Marc Mutz"
> bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
>
> marc.m...@kdab.com> wrote:
> > >On Friday 18 March 2016 15:37:4
On 18 Mar 2016, at 08:48, Jędrzej Nowacki
mailto:jedrzej.nowa...@theqtcompany.com>>
wrote:
Every time someone discuss coding style issues my blood boils. I understand
that it is important to have consistent coding style, but discussing where to
put braces or spaces is just waste of developing t
49 matches
Mail list logo