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