I agree with everything Ondrej said. Aaron Meurer
On Wed, Jan 7, 2015 at 11:38 AM, Ondřej Čertík <[email protected]> wrote: > On Wed, Jan 7, 2015 at 11:24 AM, Joachim Durchholz <[email protected]> > wrote: > > Am 07.01.2015 um 18:14 schrieb Chris Smith: > >> > >> I can't think of a compelling reason not to always use multiples of 4. > > > > > > "Don't forbid stuff unless necessary" would be one :-) > > > >> WRT > >> > >> the continuation of parameters, one may just move all parameters down to > >> the next indent as > >> > >> def foo( > >> a, b, c, > >> d, e, f): > > > > > > That's an indent of nine spaces. I suppose that's unintentional, I guess > you > > meant to say > > > > def x( > > a, b, c > > d, e, f): > > # first line of x > > > > This would work, and allow a simple "every indent no matter what should > be a > > multiple of four" rule, fit for check_code_quality. > > > > However, it would probably annoy some people, because it goes beyond the > > PEP8 consensus, which allow almost arbitrary indents on this kind of > > continuation line (technically, an indent of 1 would be permissible). > > > > Here are my opinions: > > > The question here is: Is an easier check worth the additional annoyance? > > No. > > > Is the better code conformity (which makes it easier to scan quickly) > worth > > it? > > No. > > > How bad is the annoyance? > > Bad. We should only check the very bad stuff like implicit imports or > trailing whitespace. > > > It means that if you run bin/test before issuing > > the pull request, you may have to go over your code and fix a dozen or > more > > lines. How would people feel about that? > > I would be annoyed. > > > Would they consider that > > bondage&discipline, or would they accept that on the basis of "ah well > > whatever"? > > If the code quality is low, the pull request reviewer should bring > this up in each particular case. We should use 4 spaces for > indentation, but we should allow exceptions and multiline statements > seem like one. > > My suggestion would be to move on to do some more productive work than > worry about this. > > Ondrej > > > > > I have no universal answers for these questions; it's essentially all > > judgement calls. > > I have one vague and not very definitive answer: large projects generally > > tend to have even stricter style guidelines; the most well-known being > > Linux, and the GNU software collection. > > > > Not having definitive answers is the reason why I'm asking for votes :-) > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CADDwiVDvU9ZdZs3OmBp3JzL0kHKv4oZ1Ng7buTH2Q0EnZM18BQ%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LX9OskY0ewF%2BO971bUetVcSi-8xk8Y%2Br3AMh%3DceLbLsA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
