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