> 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 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 > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > 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
