D pullrequest review process rant

[Nick Sabalausky]

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 <thelastmammoth at 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
> <code at 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