I've created a PR with astyle settings so that everyone can see how the
code looks then.
It seems to me astyle has less problems with a variable line-length then
clang-format.
The conversion of the code base could be done piece by piece. We just
decide to use the auto-formatter from some point
Hello,
With Mixxx I use astyle:
astyle --style=java --pad-header -s4 --lineend=linux
--max-code-length=80 --break-after-logical --convert-tabs file.cpp
it seems that they also have Google style and pico style (what ever
that means but I'll start to use it). I prefer 120 because hey it's
2015. I
When pros and cons are balanced, the better way to decide is :
https://www.random.org/coins/?num=1&cur=20-novelty.decision-maker [3]
Here, it is a matter of taste and not everybody can agree, so there
should be one predominent vote, from "the project owner" or whatever
member is more legitim
On Thu, 2015-06-11 at 14:08 +, Gavin Swanson wrote:
> Compromise = 120 Columns
No, the people who prefer 80 columns have specific reasons for that
value -- specific window sizes, compatibility with existing code, etc
etc. My point is that this is a case where there is not a compromise
and we
> So we have people who prefer 80 columns, and people who prefer unlimited
columns. There's not really a compromise position between these two
options, so how do we choose?
We have people who prefer 80 columns and we have people who prefer more.
I prefer 80 columns.
So there is no column issue is
Compromise = 120 Columns
My main issue with 80 column split:
Modern IDEs provide some kind of Tab Completion like capability which
lessons the pain of writing out (reasonably) long descriptive variable and
function names (which everyone should be doing). When your using these
longer names you end
So we have people who prefer 80 columns, and people who prefer unlimited
columns. There's not really a compromise position between these two
options, so how do we choose?
On Wed, 2015-06-10 at 09:28 -0400, Owen Williams wrote:
> On Wed, 2015-06-10 at 09:16 -0400, RJ Ryan wrote:
> >
>
> >
> >
Hi,
I have played a bit with clang-format and it turns out that
we need
AlwaysBreakBeforeMultilineStrings: false
ColumnLimit: 0
To fix most cluttering the issues.
But now we have a new one:
Double indentation fails in certain palaces.
Am 10.06.2015 um 17:01 schrieb Max Linke:
>
>
> On 06/10
On 06/10/2015 04:16 PM, Daniel Schürmann wrote:
> Which version of clang-format do you use?
> Can this be a bug like this:
> https://github.com/travisjeffery/ClangFormat-Xcode/issues/81
>
> Can you give an example where ColumnLimit: 0 fails?
I use clang-format-3.6
> QLayout* pLayout = NULL
Which version of clang-format do you use?
Can this be a bug like this:
https://github.com/travisjeffery/ClangFormat-Xcode/issues/81
Can you give an example where ColumnLimit: 0 fails?
Searching gitHub there are a lot of projects using ColumnLimit: 0
https://github.com/search?q=ColumnLimit%3A+0&ty
On 06/10/2015 03:31 PM, Daniel Schürmann wrote:
> I think we should give ColumnLimit: 0 a try.
>
> "A column limit of 0 means that there is no column limit. In this case,
> clang-format will respect the input's line breaking decisions within
> statements unless they contradict other rules."
I just
I think we should give ColumnLimit: 0 a try.
"A column limit of 0 means that there is no column limit. In this case,
clang-format will respect the input's line breaking decisions within
statements unless they contradict other rules."
2015-06-10 15:28 GMT+02:00 Owen Williams :
> On Wed, 2015-06
On Wed, 2015-06-10 at 09:16 -0400, RJ Ryan wrote:
>
>
>
> The part of clang-format which frees you from having to talk about
> code style is that there is only one right way to format the code.
> Letting the developer have any choice in the matter goes against this.
>
Agree. I don't really
On Wed, Jun 10, 2015 at 5:31 AM, Daniel Schürmann
wrote:
> The idea is to use a none or a big (115) column count for the mass auto
> format, to get around the code cluttering.
>
> The 80 size may be part of a second clang script that is intended to be
> invoked manually during editing.
> If clang
On Wed, Jun 10, 2015 at 9:09 AM, Gavin Swanson
wrote:
> If clang can't do a smart auto line length like we're talking about, just
> disable the auto line length portion of clang. Continue to use it for
> parens etc.
>
clang-format always reformats every line to match its rules. So if it sees
a st
If clang can't do a smart auto line length like we're talking about, just
disable the auto line length portion of clang. Continue to use it for
parens etc.
Most editors can display vertical lines at various locations. Put a line at
80 and one at 115. Use then as reference and make a judgement call
The idea is to use a none or a big (115) column count for the mass auto
format, to get around the code cluttering.
The 80 size may be part of a second clang script that is intended to be
invoked manually during editing.
If clang produces less readable code, the developer is still there to fix
it.
On 06/10/2015 10:05 AM, Daniel Schürmann wrote:
> @Max: Are the current line length in Mixxx working for you?
I haven't noticed anything with the current line lengths. In the end it
doesn't matter much for me which line-length we choose. I just wanted to
mention that 80 seems to be a value that
@Max: Are the current line length in Mixxx working for you?
If yes, we can continue with the 80 as a "not a strict requirement".
We may use 80 as a setting while editing (Ctrl-Shift-F), but not break
lines during a mass auto-format.
2015-06-10 9:44 GMT+02:00 Max Linke :
>
>
> On 06/10/2015 08:20
On 06/10/2015 08:20 AM, Daniel Schürmann wrote:
> I think we have two external limits for code length, the historical 80
> columns and the 115 columns in GitHub pull requests.
> Our 80 columns is already "not a strict requirement", changing it to a
> strict requirement and auto-reformat it, clutt
> I personally like a variant of the Go formatting rules, which are
basically "don't worry about line length".
This sound like good approach for an an auto- formatter.
I think we have two external limits for code length, the historical 80
columns and the 115 columns in GitHub pull requests.
Our
I agree that 80 columns is restrictive with 4-space tabs. I personally
like a variant of the Go formatting rules, which are basically "don't
worry about line length". I aim for 100, but if something is a few
characters over, I let it go long. No one wants to scroll horizontally,
but I also disli
If auto line breaking is done, I could support 120+. The old 80 char limit
doesn't make sense anymore.
On Tue, Jun 9, 2015, 3:03 PM Daniel Schürmann wrote:
> After skimming though the PR, I can see my objections confirmed
> regarding auto formated line breaks.
> On the other hand I see that mos
After skimming though the PR, I can see my objections confirmed
regarding auto formated line breaks.
On the other hand I see that most other issues are handled well.
I think I will support such mass refactoring, if it does not introduce
line breaks.
For my feeling we have no readability issues w
Example:
https://github.com/mixxxdj/mixxx/pull/616
On Tue, Jun 9, 2015 at 4:52 PM, Max Linke wrote:
>
>
> On 06/09/2015 10:08 PM, RJ Ryan wrote:
>
>> I'm for this -- we waste too much time arguing about code style and spend
>> way too much time cleaning up code.
>>
>> We do differ from Google C+
On 06/09/2015 10:08 PM, RJ Ryan wrote:
I'm for this -- we waste too much time arguing about code style and spend
way too much time cleaning up code.
We do differ from Google C++ style in certain ways. I'm for eliminating
most of the differences.
+1
But I also attach the clang-format file I
On 06/09/2015 01:08 PM, RJ Ryan wrote:
It looks like reformatting the world will change about 32k lines. That's
a small price to pay for never having to worry about this again.
Well shoot, let's do it in master tomorrow. Seriously.
Sincerely,
Sean M. Pappalardo
"D.J. Pegasus"
Mixxx Develope
I'm for this -- we waste too much time arguing about code style and spend
way too much time cleaning up code.
We do differ from Google C++ style in certain ways. I'm for eliminating
most of the differences.
We should do a 1-step reformat-the-world and then distribute a commit hook
to reformat. Th
On 06/08/2015 09:51 AM, Sébastien BLAISOT wrote:
>
>
> Hi,
>
> I did recently, as asked by RJ, added some coding style commit in a PR,
> particularly on the following rule:
>
> _Plain-text comments should be separated from the comment symbol by a
> single space. Commented-out code should have no
On 06/08/2015 09:22 AM, Daniel Schürmann wrote:
Hi,
I have some good experience with the Eclipse Formatter:
http://www.mixxx.org/wiki/doku.php/eclipse?s[]=eclipse#eclipse_code_formatter
We have to be careful not to put clutter on a PR just because using an auto
formatter.
This may happens if
Hi,
I did recently, as asked by RJ, added some coding style commit in a PR,
particularly on the following rule:
_Plain-text comments should be separated from the comment symbol by a
single space. Commented-out code should have no space between the
comment symbol and the code_
I'm not sure
Hi,
I have some good experience with the Eclipse Formatter:
http://www.mixxx.org/wiki/doku.php/eclipse?s[]=eclipse#eclipse_code_formatter
We have to be careful not to put clutter on a PR just because using an auto
formatter.
This may happens if an auto formatter changes code that already meets t
There is really no way to port this. It is the configuration file for
`clang-format` a separate program. Since I only use emacs I don't know
how to best use it in other editors.
you can find more information here
http://clang.llvm.org/docs/ClangFormat.html
Just try to google clang-format + you
Hello,
Can you port this to astyle because not everyone are using Emacs or
something silmilar for more convient use.
Thanks,
Tuukka
2015-06-06 21:43 GMT+03:00 Max Linke :
> Hi
>
> We had some recurring discussions in the PR about coding style. I have
> recently started to rely on clang-format wit
Hi
We had some recurring discussions in the PR about coding style. I have
recently started to rely on clang-format with a set of predefined rules.
My emacs is configured to apply this always before I save a file. I
personally find that really nice and relaxing, I don't need to format my
code
35 matches
Mail list logo
