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
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
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
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
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
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:
The
@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 max_li...@gmx.de:
On
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
On Wed, Jun 10, 2015 at 9:09 AM, Gavin Swanson gavinswan...@gmail.com
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.
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, clutters
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 owilli...@mixxx.org:
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
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 feel
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;
-
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 80
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
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.
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 Developer
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
Example:
https://github.com/mixxxdj/mixxx/pull/616
On Tue, Jun 9, 2015 at 4:52 PM, Max Linke max_li...@gmx.de 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
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 dasch...@mixxx.org wrote:
After skimming though the PR, I can see my objections confirmed
regarding auto formated line breaks.
On the other
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
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
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
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
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 max_li...@gmx.de:
Hi
We had some recurring discussions in the PR about coding style. I have
recently started to rely on
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 +
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
30 matches
Mail list logo
