Re: [Mixxx-devel] formating source Code with clang-format
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 on and provide a git-hook script for new contributors (so git will apply astyle/clang-format before every commit). best Max On 06/11/2015 09:24 PM, Tuukka Pasanen wrote: 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 code in nano but I have wider screen! (and that's a fact) Sincerely, Tuukka 2015-06-11 17:16 GMT+03:00 Daniel Schürmann dasch...@mixxx.org: 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 issue to add a .clang-format file to the Mixxx source and ask any contributor to run it if there are style issues. The latest discussion was about the code cluttering produced by a unsupervised run at all Mixxx source. This happens because we allow currently allow more than 80 columns for reasons. Setting the columns to unlimited helps a bit. But there are still other cluttering issues that requires developer attention. Never seen astyle has broke something like code didn't work anymore. Do you have experience with Astyle. Maybe this can be configured to be more temperate than clang-format. It would be also nice if we can do the mass auto-format for single style issues only e.g. the pinter * alignment. 2015-06-11 15:30 GMT+02:00 Owen Williams owilli...@mixxx.org: 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 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 strongly about line length, so 80 is fine with me. -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 issue to add a .clang-format file to the Mixxx source and ask any contributor to run it if there are style issues. The latest discussion was about the code cluttering produced by a unsupervised run at all Mixxx source. This happens because we allow currently allow more than 80 columns for reasons. Setting the columns to unlimited helps a bit. But there are still other cluttering issues that requires developer attention. Never seen astyle has broke something like code didn't work anymore. Do you have experience with Astyle. Maybe this can be configured to be more temperate than clang-format. It would be also nice if we can do the mass auto-format for single style issues only e.g. the pinter * alignment. 2015-06-11 15:30 GMT+02:00 Owen Williams owilli...@mixxx.org: 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 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 strongly about line length, so 80 is fine with me. -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 as a project need a sane way of deciding these issues, because they come up often and it has been killing our productivity. -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 up splitting very simple lines at 80 columns, and it
ends up reducing readability.
This is an obviously contrived example, but I have run into this very issue
with 80 column limits and long variable/function names (mostly crops up due
to nesting).
void raise_importance(const listType lessImportantThingList, const
VariableTypeForImportantThings somethingImportant)
{
for(auto lessImportantThing(lessImportantThingList.begin());
lessImportantThing == lessImportantThingList.end();
lessImportantThing++)
{
if (somethingImportant == lessImportantThing)
{
VariableTypeForImportantThings moreImportantThing =
make_more_important(lessImportantThing);
}
}
}
So the function definition portion can be easily wrapped, but even then in
this example the end of the line is sitting at 79 characters, if it was a
templated type of some kind it would get harry quickly.
The line in the if can't be logically split to 80 characters in a readable
way, following most line split methods.
These are the 80 character issues I have run into. Yes they can happen with
anything less than infinite line length, but they are highly likely to
happen at 80, much less so I've found at 120.
On Thu, Jun 11, 2015 at 6:32 AM Owen Williams owilli...@mixxx.org wrote:
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 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 strongly about line length, so 80 is fine
with me.
--
___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
--
___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
--
___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 code in nano but I have wider screen! (and that's a fact) Sincerely, Tuukka 2015-06-11 17:16 GMT+03:00 Daniel Schürmann dasch...@mixxx.org: 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 issue to add a .clang-format file to the Mixxx source and ask any contributor to run it if there are style issues. The latest discussion was about the code cluttering produced by a unsupervised run at all Mixxx source. This happens because we allow currently allow more than 80 columns for reasons. Setting the columns to unlimited helps a bit. But there are still other cluttering issues that requires developer attention. Never seen astyle has broke something like code didn't work anymore. Do you have experience with Astyle. Maybe this can be configured to be more temperate than clang-format. It would be also nice if we can do the mass auto-format for single style issues only e.g. the pinter * alignment. 2015-06-11 15:30 GMT+02:00 Owen Williams owilli...@mixxx.org: 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 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 strongly about line length, so 80 is fine with me. -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 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 strongly about line length, so 80 is fine with me. -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
@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 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 the code like in the https://github.com/mixxxdj/mixxx/pull/616 Since 80 colums guarantee the best compatibility tough-out all tools and helps developers with small screens. I would like to keep the not strict target size of 80 in our prose coding rules. 80 is also good for larger screens if you want to view files next to each other. Or Compiler Errors and Code. I'm not sure about IDE's but with tools like vim/emacs/gedit is the best value if one wants to split the screen is 80 for me (tested on a FullHD 14 display without scaling and pointsize 12). I can also live with a 100 but 80 seems to be most compatible for me. Is it possible to trigger a auto Line break at 115, but once it is triggered anyway use 80? This seams to be a solution in our case. Nope not possible. We can set the PenaltyExcessCharacter to 1 but then the indentation looks weird in other places. I haven't found a settings combination that is able to produce something like this. Also no matter the there is always an odd line. 2015-06-10 0:45 GMT+02:00 Owen Williams owilli...@mixxx.org: 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 dislike heavily-wrapped statements. That said, I do like clang-format a lot, and I have eclipse set up to use it. I can just push ctrl-shift-f on any line, and it formats it for me. That way I can just write a messy line without regard for style, then let the software format it and add line breaks. Once we pick a set of clang settings, I don't want to do a lot of haggling about where clang fails -- just let it do what it wants and move on. I can live with 80 or whatever others prefer On Wed, 2015-06-10 at 00:02 +0200, 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 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 with long lines in current master, So there is no need to risk the clutter. Am 09.06.2015 um 22:54 schrieb RJ Ryan: 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 Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. 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. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: 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 space between the comment symbol and the code_ I'm not sure that this kind of rule can
Re: [Mixxx-devel] formating source Code with clang-format
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 for when to split the lines. I'd much rather raise $100 to get the guy still working on a 14 monitor something bigger, than restrict the whole project to 80. ;-) On Wed, Jun 10, 2015, 2:32 AM Daniel Schürmann dasch...@mixxx.org 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 produces less readable code, the developer is still there to fix it. It should be allowed to exceed the 80 columns for good reasons. This is the way I am already working. 2015-06-10 10:42 GMT+02:00 Max Linke max_li...@gmx.de: 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 works well for a large variety of display-sizes and work flows. If yes, we can continue with the 80 as a not a strict requirement. It doesn't work like this. Either we use a auto formatter or we don't. Things like 'not a strict requirement' cannot be expressed in the rules for clang-format afaik, nor am I aware of another that could. (I suggested clang-format because it is independent of the used tools). We may use 80 as a setting while editing (Ctrl-Shift-F), but not break lines during a mass auto-format. I don't know how this would be possible with clang-format. 2015-06-10 9:44 GMT+02:00 Max Linke max_li...@gmx.de: 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 the code like in the https://github.com/mixxxdj/mixxx/pull/616 Since 80 colums guarantee the best compatibility tough-out all tools and helps developers with small screens. I would like to keep the not strict target size of 80 in our prose coding rules. 80 is also good for larger screens if you want to view files next to each other. Or Compiler Errors and Code. I'm not sure about IDE's but with tools like vim/emacs/gedit is the best value if one wants to split the screen is 80 for me (tested on a FullHD 14 display without scaling and pointsize 12). I can also live with a 100 but 80 seems to be most compatible for me. Is it possible to trigger a auto Line break at 115, but once it is triggered anyway use 80? This seams to be a solution in our case. Nope not possible. We can set the PenaltyExcessCharacter to 1 but then the indentation looks weird in other places. I haven't found a settings combination that is able to produce something like this. Also no matter the there is always an odd line. 2015-06-10 0:45 GMT+02:00 Owen Williams owilli...@mixxx.org: 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 dislike heavily-wrapped statements. That said, I do like clang-format a lot, and I have eclipse set up to use it. I can just push ctrl-shift-f on any line, and it formats it for me. That way I can just write a messy line without regard for style, then let the software format it and add line breaks. Once we pick a set of clang settings, I don't want to do a lot of haggling about where clang fails -- just let it do what it wants and move on. I can live with 80 or whatever others prefer On Wed, 2015-06-10 at 00:02 +0200, 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 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 with long lines in current master, So there is no need to risk the clutter. Am 09.06.2015 um 22:54 schrieb RJ Ryan: 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
Re: [Mixxx-devel] formating source Code with clang-format
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. So if it sees a statement that is split across 3 lines that could be written all in one line per the rules then it will reformat that line to be all one line. The end result of disabling the line length limit is that Clang will reformat every statement in the codebase that is currently broken across multiple lines to be on one line. 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 for when to split the lines. I'd much rather raise $100 to get the guy still working on a 14 monitor something bigger, than restrict the whole project to 80. ;-) Heh -- seriously though Max is right about 80 columns. It makes tiling windows and use in a smaller screen (e.g. laptop) environment much nicer. On Wed, Jun 10, 2015, 2:32 AM Daniel Schürmann dasch...@mixxx.org 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 produces less readable code, the developer is still there to fix it. It should be allowed to exceed the 80 columns for good reasons. This is the way I am already working. 2015-06-10 10:42 GMT+02:00 Max Linke max_li...@gmx.de: 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 works well for a large variety of display-sizes and work flows. If yes, we can continue with the 80 as a not a strict requirement. It doesn't work like this. Either we use a auto formatter or we don't. Things like 'not a strict requirement' cannot be expressed in the rules for clang-format afaik, nor am I aware of another that could. (I suggested clang-format because it is independent of the used tools). We may use 80 as a setting while editing (Ctrl-Shift-F), but not break lines during a mass auto-format. I don't know how this would be possible with clang-format. 2015-06-10 9:44 GMT+02:00 Max Linke max_li...@gmx.de: 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 the code like in the https://github.com/mixxxdj/mixxx/pull/616 Since 80 colums guarantee the best compatibility tough-out all tools and helps developers with small screens. I would like to keep the not strict target size of 80 in our prose coding rules. 80 is also good for larger screens if you want to view files next to each other. Or Compiler Errors and Code. I'm not sure about IDE's but with tools like vim/emacs/gedit is the best value if one wants to split the screen is 80 for me (tested on a FullHD 14 display without scaling and pointsize 12). I can also live with a 100 but 80 seems to be most compatible for me. Is it possible to trigger a auto Line break at 115, but once it is triggered anyway use 80? This seams to be a solution in our case. Nope not possible. We can set the PenaltyExcessCharacter to 1 but then the indentation looks weird in other places. I haven't found a settings combination that is able to produce something like this. Also no matter the there is always an odd line. 2015-06-10 0:45 GMT+02:00 Owen Williams owilli...@mixxx.org: 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 dislike heavily-wrapped statements. That said, I do like clang-format a lot, and I have eclipse set up to use it. I can just push ctrl-shift-f on any line, and it formats it for me. That way I can just write a messy line without regard for style, then let the software format it and add line breaks. Once we pick a set of clang settings, I don't want to do a lot of haggling about where clang fails -- just let it do what it wants and move on. I can live with 80 or whatever others prefer On Wed, 2015-06-10 at 00:02 +0200, 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
Re: [Mixxx-devel] formating source Code with clang-format
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 the code like in the https://github.com/mixxxdj/mixxx/pull/616 Since 80 colums guarantee the best compatibility tough-out all tools and helps developers with small screens. I would like to keep the not strict target size of 80 in our prose coding rules. 80 is also good for larger screens if you want to view files next to each other. Or Compiler Errors and Code. I'm not sure about IDE's but with tools like vim/emacs/gedit is the best value if one wants to split the screen is 80 for me (tested on a FullHD 14 display without scaling and pointsize 12). I can also live with a 100 but 80 seems to be most compatible for me. Is it possible to trigger a auto Line break at 115, but once it is triggered anyway use 80? This seams to be a solution in our case. Nope not possible. We can set the PenaltyExcessCharacter to 1 but then the indentation looks weird in other places. I haven't found a settings combination that is able to produce something like this. Also no matter the there is always an odd line. 2015-06-10 0:45 GMT+02:00 Owen Williams owilli...@mixxx.org: 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 dislike heavily-wrapped statements. That said, I do like clang-format a lot, and I have eclipse set up to use it. I can just push ctrl-shift-f on any line, and it formats it for me. That way I can just write a messy line without regard for style, then let the software format it and add line breaks. Once we pick a set of clang settings, I don't want to do a lot of haggling about where clang fails -- just let it do what it wants and move on. I can live with 80 or whatever others prefer On Wed, 2015-06-10 at 00:02 +0200, 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 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 with long lines in current master, So there is no need to risk the clutter. Am 09.06.2015 um 22:54 schrieb RJ Ryan: 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 Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. 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. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: 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 space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the
Re: [Mixxx-devel] formating source Code with clang-format
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 tested that and it doesn't. This makes the line break rather unpredictable. Some function calls suddenly get split across multiply lines for no apparent reason. 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. +1 -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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: 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 strongly about line length, so 80 is fine with me. -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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+0type=Codeutf8=%E2%9C%93 2015-06-10 15:53 GMT+02:00 Max Linke max_li...@gmx.de: 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 tested that and it doesn't. This makes the line break rather unpredictable. Some function calls suddenly get split across multiply lines for no apparent reason. 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. +1 -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 strongly about line length, so 80 is fine with me. -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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;
-if (context.hasNode(node, Layout)) {
-QString layout = context.selectString(node, Layout);
-if (layout == vertical) {
+if (context.hasNode(node,
+Layout)) {
+QString layout = context.selectString(node,
+ Layout);
+if (layout ==
+vertical) {
pLayout = new QVBoxLayout();
-} else if (layout == horizontal) {
+} else if (layout ==
+ horizontal) {
pLayout = new QHBoxLayout();
-} else if (layout == stacked) {
+} else if (layout ==
+ stacked) {
This doesn't happen if I set the column limit to 80
--
___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 columns is already not a strict requirement, changing it to a strict requirement and auto-reformat it, clutters the code like in the https://github.com/mixxxdj/mixxx/pull/616 Since 80 colums guarantee the best compatibility tough-out all tools and helps developers with small screens. I would like to keep the not strict target size of 80 in our prose coding rules. If we decide for a strong limit we may pick a value 100 .. 115 to get around vertical scrolling in GitHub. Is it possible to trigger a auto Line break at 115, but once it is triggered anyway use 80? This seams to be a solution in our case. 2015-06-10 0:45 GMT+02:00 Owen Williams owilli...@mixxx.org: 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 dislike heavily-wrapped statements. That said, I do like clang-format a lot, and I have eclipse set up to use it. I can just push ctrl-shift-f on any line, and it formats it for me. That way I can just write a messy line without regard for style, then let the software format it and add line breaks. Once we pick a set of clang settings, I don't want to do a lot of haggling about where clang fails -- just let it do what it wants and move on. I can live with 80 or whatever others prefer On Wed, 2015-06-10 at 00:02 +0200, 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 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 with long lines in current master, So there is no need to risk the clutter. Am 09.06.2015 um 22:54 schrieb RJ Ryan: 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 Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. 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. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: 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 space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for
Re: [Mixxx-devel] formating source Code with clang-format
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/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;
-if (context.hasNode(node, Layout)) {
-QString layout = context.selectString(node, Layout);
-if (layout == vertical) {
+if (context.hasNode(node,
+Layout)) {
+QString layout = context.selectString(node,
+ Layout);
+if (layout ==
+vertical) {
pLayout = new QVBoxLayout();
-} else if (layout == horizontal) {
+} else if (layout ==
+ horizontal) {
pLayout = new QHBoxLayout();
-} else if (layout == stacked) {
+} else if (layout ==
+ stacked) {
This doesn't happen if I set the column limit to 80
--
___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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. That will prevent a lot of unrelated noise in PRs. 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. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: 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 space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 - Controller Specialist smime.p7s Description: S/MIME Cryptographic Signature -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. 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. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: 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 space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel --- Language:Cpp # BasedOnStyle: Google AccessModifierOffset: -2 AlignAfterOpenBracket: true AlignEscapedNewlinesLeft: true AlignOperands: true AlignTrailingComments: true AllowAllParametersOfDeclarationOnNextLine: true AllowShortBlocksOnASingleLine: false AllowShortCaseLabelsOnASingleLine: false AllowShortIfStatementsOnASingleLine: false AllowShortLoopsOnASingleLine: false AllowShortFunctionsOnASingleLine: Inline AlwaysBreakAfterDefinitionReturnType: false AlwaysBreakTemplateDeclarations: true AlwaysBreakBeforeMultilineStrings: true BreakBeforeBinaryOperators: None BreakBeforeTernaryOperators: true BreakConstructorInitializersBeforeComma: false BinPackParameters: true BinPackArguments: true ColumnLimit: 80 ConstructorInitializerAllOnOneLineOrOnePerLine: true ConstructorInitializerIndentWidth: 8 DerivePointerAlignment: true ExperimentalAutoDetectBinPacking: false IndentCaseLabels: true IndentWrappedFunctionNames: false IndentFunctionDeclarationAfterType: false MaxEmptyLinesToKeep: 1 KeepEmptyLinesAtTheStartOfBlocks: false NamespaceIndentation: None ObjCBlockIndentWidth: 2 ObjCSpaceAfterProperty: false ObjCSpaceBeforeProtocolList: false PenaltyBreakBeforeFirstCallParameter: 1 PenaltyBreakComment: 300 PenaltyBreakString: 1000 PenaltyBreakFirstLessLess: 120 PenaltyExcessCharacter: 100 PenaltyReturnTypeOnItsOwnLine: 200 PointerAlignment: Left SpacesBeforeTrailingComments: 1 Cpp11BracedListStyle: true Standard:Auto IndentWidth: 4 TabWidth:4 UseTab: Never BreakBeforeBraces: Attach SpacesInParentheses: false SpacesInSquareBrackets: false SpacesInAngles: false SpaceInEmptyParentheses: false SpacesInCStyleCastParentheses: false SpaceAfterCStyleCast: false SpacesInContainerLiterals: true SpaceBeforeAssignmentOperators: true ContinuationIndentWidth: 8 CommentPragmas: '^ IWYU pragma:' ForEachMacros: [ foreach, Q_FOREACH, BOOST_FOREACH ] SpaceBeforeParens: ControlStatements DisableFormat: false ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. 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. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: 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 space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 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 with long lines in current master, So there is no need to risk the clutter. Am 09.06.2015 um 22:54 schrieb RJ Ryan: 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 Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. 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. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: 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 space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Todayhttp://mixxx.org Mixxx-devel mailing listMixxx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 dislike heavily-wrapped statements. That said, I do like clang-format a lot, and I have eclipse set up to use it. I can just push ctrl-shift-f on any line, and it formats it for me. That way I can just write a messy line without regard for style, then let the software format it and add line breaks. Once we pick a set of clang settings, I don't want to do a lot of haggling about where clang fails -- just let it do what it wants and move on. I can live with 80 or whatever others prefer On Wed, 2015-06-10 at 00:02 +0200, 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 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 with long lines in current master, So there is no need to risk the clutter. Am 09.06.2015 um 22:54 schrieb RJ Ryan: 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 Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. 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. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: 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 space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ...
Re: [Mixxx-devel] formating source Code with clang-format
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 with long lines in current master, So there is no need to risk the clutter. Am 09.06.2015 um 22:54 schrieb RJ Ryan: Example: https://github.com/mixxxdj/mixxx/pull/616 On Tue, Jun 9, 2015 at 4:52 PM, Max Linke max_li...@gmx.de mailto: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 Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. 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. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de mailto:max_li...@gmx.de wrote: 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 space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net mailto:Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- Sébastien BLAISOT Le 08/06/2015 09:22, Daniel Schürmann a écrit : Hi, I have some good experience with the Eclipse Formatter: http://www.mixxx.org/wiki/doku.php/eclipse?s[]=eclipse#eclipse_code_formatter [1] 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 the requirements. Therefor I prefer the way Eclipse works, It supports you as much as possible while editing. It does not reformat the code except you ask for it Ctrl-Shift-F What may help, In the Mixxx project is a build chain tool that warns about code style violations. Kind regards, Daniel 2015-06-07 11:54 GMT+02:00 Max Linke max_li...@gmx.de: 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 [2] Just try to google clang-format + your favorite editor ecplise: https://github.com/wangzw/cppstyle [3] sublime: https://github.com/rosshemsley/SublimeClangFormat [4] creator: https://www.snip2code.com/Snippet/11436/Configuration-of-clang-format-for-QtCrea [5] You can also always use it from the CLI clang-format -i [file1 ... ] I missed some indentation settings in the yesterday. Attached is an updated file. best Max On 06/07/2015 11:18 AM, Tuukka Pasanen wrote: 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 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 manually anymore and every time I touch a file it automatically looks nice. I attached the clang-format file I use for mixxx. It is based on the Google style with our indentation rules. This would also help in a PR because we can just point them to clang-format. I don't have experience with other editors besides emacs but I guess it should be also possible in a something like vim or eclipse. What do you think? Would others like to use this as well? best Max -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org [6] Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel [7] -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org [6] Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel [7] -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org [6] Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel [7] -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org [6] Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel [7] Links: -- [1] http://www.mixxx.org/wiki/doku.php/eclipse?s[]=eclipse#eclipse_code_formatter [2] http://clang.llvm.org/docs/ClangFormat.html [3] https://github.com/wangzw/cppstyle [4] https://github.com/rosshemsley/SublimeClangFormat [5] https://www.snip2code.com/Snippet/11436/Configuration-of-clang-format-for-QtCrea [6] http://mixxx.org [7] https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net
Re: [Mixxx-devel] formating source Code with clang-format
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 the requirements. Therefor I prefer the way Eclipse works, It supports you as much as possible while editing. It does not reformat the code except you ask for it Ctrl-Shift-F What may help, In the Mixxx project is a build chain tool that warns about code style violations. Kind regards, Daniel 2015-06-07 11:54 GMT+02:00 Max Linke max_li...@gmx.de: 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 + your favorite editor ecplise: https://github.com/wangzw/cppstyle sublime: https://github.com/rosshemsley/SublimeClangFormat creator: https://www.snip2code.com/Snippet/11436/Configuration-of-clang-format-for-QtCrea You can also always use it from the CLI clang-format -i [file1 ... ] I missed some indentation settings in the yesterday. Attached is an updated file. best Max On 06/07/2015 11:18 AM, Tuukka Pasanen wrote: 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 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 manually anymore and every time I touch a file it automatically looks nice. I attached the clang-format file I use for mixxx. It is based on the Google style with our indentation rules. This would also help in a PR because we can just point them to clang-format. I don't have experience with other editors besides emacs but I guess it should be also possible in a something like vim or eclipse. What do you think? Would others like to use this as well? best Max -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 an auto formatter changes code that already meets the requirements. Then we need to adjust the auto formatter rules ;). I fixed some more things in the format file (Seems like we differ quite a lot from the google style actually) Therefor I prefer the way Eclipse works, It supports you as much as possible while editing. It does not reformat the code except you ask for it Ctrl-Shift-F Emacs is also able to do this. It is just a matter of what people prefer. I assume other IDE's can also do that. I just thought this is a nice way for people to automatically have there coding styles fixed without having to setup their IDE completely for mixxx. I think saying run `clang-format -i files-you-edited` once in a PR might be nicer then all the nit-pick comments we are doing now. What may help, In the Mixxx project is a build chain tool that warns about code style violations. Would be nice. Then we would get all the warning where we still violate our own style. Kind regards, Daniel 2015-06-07 11:54 GMT+02:00 Max Linke max_li...@gmx.de: 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 + your favorite editor ecplise: https://github.com/wangzw/cppstyle sublime: https://github.com/rosshemsley/SublimeClangFormat creator: https://www.snip2code.com/Snippet/11436/Configuration-of-clang-format-for-QtCrea You can also always use it from the CLI clang-format -i [file1 ... ] I missed some indentation settings in the yesterday. Attached is an updated file. best Max On 06/07/2015 11:18 AM, Tuukka Pasanen wrote: 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 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 manually anymore and every time I touch a file it automatically looks nice. I attached the clang-format file I use for mixxx. It is based on the Google style with our indentation rules. This would also help in a PR because we can just point them to clang-format. I don't have experience with other editors besides emacs but I guess it should be also possible in a something like vim or eclipse. What do you think? Would others like to use this as well? best Max -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel --- Language:Cpp # BasedOnStyle: Google AccessModifierOffset: -2 AlignAfterOpenBracket: true AlignEscapedNewlinesLeft: true AlignOperands: true AlignTrailingComments: true AllowAllParametersOfDeclarationOnNextLine: true AllowShortBlocksOnASingleLine: false AllowShortCaseLabelsOnASingleLine: false AllowShortIfStatementsOnASingleLine: false AllowShortLoopsOnASingleLine: false AllowShortFunctionsOnASingleLine: Inline AlwaysBreakAfterDefinitionReturnType: false AlwaysBreakTemplateDeclarations: true AlwaysBreakBeforeMultilineStrings: true BreakBeforeBinaryOperators: None BreakBeforeTernaryOperators: true BreakConstructorInitializersBeforeComma: false BinPackParameters: true BinPackArguments: true ColumnLimit: 80 ConstructorInitializerAllOnOneLineOrOnePerLine: true ConstructorInitializerIndentWidth: 8 DerivePointerAlignment: true ExperimentalAutoDetectBinPacking: false IndentCaseLabels: true IndentWrappedFunctionNames: false IndentFunctionDeclarationAfterType:
Re: [Mixxx-devel] formating source Code with clang-format
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 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 manually anymore and every time I touch a file it automatically looks nice. I attached the clang-format file I use for mixxx. It is based on the Google style with our indentation rules. This would also help in a PR because we can just point them to clang-format. I don't have experience with other editors besides emacs but I guess it should be also possible in a something like vim or eclipse. What do you think? Would others like to use this as well? best Max -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
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 + your favorite editor ecplise: https://github.com/wangzw/cppstyle sublime: https://github.com/rosshemsley/SublimeClangFormat creator: https://www.snip2code.com/Snippet/11436/Configuration-of-clang-format-for-QtCrea You can also always use it from the CLI clang-format -i [file1 ... ] I missed some indentation settings in the yesterday. Attached is an updated file. best Max On 06/07/2015 11:18 AM, Tuukka Pasanen wrote: 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 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 manually anymore and every time I touch a file it automatically looks nice. I attached the clang-format file I use for mixxx. It is based on the Google style with our indentation rules. This would also help in a PR because we can just point them to clang-format. I don't have experience with other editors besides emacs but I guess it should be also possible in a something like vim or eclipse. What do you think? Would others like to use this as well? best Max -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel --- Language:Cpp # BasedOnStyle: Google AccessModifierOffset: -2 AlignAfterOpenBracket: true AlignEscapedNewlinesLeft: true AlignOperands: true AlignTrailingComments: true AllowAllParametersOfDeclarationOnNextLine: true AllowShortBlocksOnASingleLine: false AllowShortCaseLabelsOnASingleLine: false AllowShortIfStatementsOnASingleLine: true AllowShortLoopsOnASingleLine: true AllowShortFunctionsOnASingleLine: All AlwaysBreakAfterDefinitionReturnType: false AlwaysBreakTemplateDeclarations: true AlwaysBreakBeforeMultilineStrings: true BreakBeforeBinaryOperators: None BreakBeforeTernaryOperators: true BreakConstructorInitializersBeforeComma: false BinPackParameters: true BinPackArguments: true ColumnLimit: 80 ConstructorInitializerAllOnOneLineOrOnePerLine: true ConstructorInitializerIndentWidth: 8 DerivePointerAlignment: true ExperimentalAutoDetectBinPacking: false IndentCaseLabels: true IndentWrappedFunctionNames: false IndentFunctionDeclarationAfterType: false MaxEmptyLinesToKeep: 1 KeepEmptyLinesAtTheStartOfBlocks: false NamespaceIndentation: None ObjCBlockIndentWidth: 2 ObjCSpaceAfterProperty: false ObjCSpaceBeforeProtocolList: false PenaltyBreakBeforeFirstCallParameter: 1 PenaltyBreakComment: 300 PenaltyBreakString: 1000 PenaltyBreakFirstLessLess: 120 PenaltyExcessCharacter: 100 PenaltyReturnTypeOnItsOwnLine: 200 PointerAlignment: Left SpacesBeforeTrailingComments: 2 Cpp11BracedListStyle: true Standard:Auto IndentWidth: 4 TabWidth:4 UseTab: Never BreakBeforeBraces: Attach SpacesInParentheses: false SpacesInSquareBrackets: false SpacesInAngles: false SpaceInEmptyParentheses: false SpacesInCStyleCastParentheses: false SpaceAfterCStyleCast: false SpacesInContainerLiterals: true SpaceBeforeAssignmentOperators: true ContinuationIndentWidth: 8 CommentPragmas: '^ IWYU pragma:' ForEachMacros: [ foreach, Q_FOREACH, BOOST_FOREACH ] SpaceBeforeParens: ControlStatements DisableFormat: false ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
