Personally, I find that good readability sometimes dictates selective exceptions to a codebase's usual style guidelines. That is, I find that code formatting rules are best used as general guideline or rules-of-thumb, rather than strict hard and fast rules. Automated formatting enforcement would get in the way of that.
That said, I certainly understand the need for and benefits of minimizing manual overhead in the whole submissions process. So I'm not going to say that I'm opposed to the idea, merely putting out my $0.02 FWIW. On Wed, 8 May 2013 10:13:15 -0700 Timothee Cour <thelastmamm...@gmail.com> wrote: > I agree with deadalnix, we need a dfmt tool to autoformat submissions. > Then this problem goes away. > uncrustify has support for D, we just need to write the options file > that everyone agrees upon, or, even better, a custom tool. > We could also automate the formatting part of the review process by > running a linter that checks that code==format(code) and automatically > rejects code that violates this. Saves a lot of time for both writer > and reviewer. These tools are used very effectively in some companies. > > > On Wed, May 8, 2013 at 8:10 AM, Benjamin Thaut > <c...@benjamin-thaut.de> wrote: > > Am 08.05.2013 17:07, schrieb deadalnix: > > > >> nit is important. > >> > >> When you read a lot of code, if the presentation is correct, it > >> disappear and the content become apparent. Otherwise, it is much > >> more work to get to the content. > >> > >> Many project simply reject code that is not formatted properly. Not > >> kidding ! > >> > >> The solution is o provide a code formatter here, not to change the > >> review process. > > > > > > I didn't say that nitpicking is not important, but it has to happen > > at the right time. > > > > > > -- > > Kind Regards > > Benjamin Thaut
