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