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