if, continuation and indentation
HH
continuation and indentation, specifically in the case of an if
statement.
When I write an if statement with many conditions, I prefer to use a
parenthesis around the whole block and get the implicit continuation,
rather than ending each line with an escape character. Thus, using
the example from the style guide (http://www.python.org/dev/peps/
pep-0008/) I would write:
if (width == 0 and
height == 0 and
color == 'red' and
emphasis == 'strong' or
highlight > 100):
raise ValueError("sorry, you lose")
The problem should be obvious -- it's not easy to see where the
conditional ends and the statement begins since they have the same
indentation. Part of the problem, I suppose, is that Emacs indents
'height' and the other lines in the conditional to 4 spaces (because
of the parenthesis). How do people deal with this situation?
Thanks,
Henrik
Martin P. Hellwig
Well style guide aside (if pylint is happy with it, so am I) it depends
on what I want to emphasize.
For example if it is really one long line with every item in it being
equally important I do this:
if width == 0 and height == 0 and color == 'red' and emphasis ==
'strong' \
or
highlight > 100:
raise ValueError("sorry, you lose")
In case it doesn't display correctly, I break up the line to nearest
80th character and align the remaining part on the next line to the
right to the 80th character.
If I want to emphasize visually a certain part I would do something like
this:
if width == 0 and height == 0 and color == 'red' \
and emphasis == 'strong' or highlight > 100:
raise ValueError("sorry, you lose")
But these are my preference, and since it is most likely that I have to
read again what I have written I write it in a way that it is most
readable to me within the constraints of pylint.
--
mph
Jean-Michel Pichavant
if (
width == 0 and
height == 0 and
color == 'red' and
emphasis == 'strong' or
highlight > 100
):
raise ValueError("sorry, you lose")
JM
Tim Chase
> When I write an if statement with many conditions, I prefer to use a
> parenthesis around the whole block and get the implicit continuation,
> rather than ending each line with an escape character. Thus, using
> the example from the style guide (http://www.python.org/dev/peps/
> pep-0008/) I would write:
>
> if (width == 0 and
> height == 0 and
> color == 'red' and
> emphasis == 'strong' or
> highlight> 100):
> raise ValueError("sorry, you lose")
While it's not PEP material, I tend to use the coding standards I
learned working for Computer Sciences Corporation (10 yrs ago, so
things may have changed) that mandated 2 levels of indentation
for continued lines, turning the above into
if (width == 0 and
height == 0 and
color == 'red' and
emphasis == 'strong' or
highlight> 100):
# or the closing "):" on this line,
# aligned with the previous line
raise ValueError("sorry, you lose")
which is fairly close to Jean-Michel's proposal.
-tkc
MRAB
if (width == 0 and
height == 0 and
color == 'red' and
emphasis == 'strong' or
highlight > 100):
raise ValueError("sorry, you lose")
Try doing that with tabs! :-)
Harald Luessen
>I have a question about best practices when it comes to line wrapping/
>continuation and indentation, specifically in the case of an if
>statement.
>
> if (width == 0 and
> height == 0 and
> color == 'red' and
> emphasis == 'strong' or
> highlight > 100):
> raise ValueError("sorry, you lose")
My solution would probably look like this:
if ( width == 0
and height == 0
and color == 'red'
and emphasis == 'strong'
or highlight > 100
):
raise ValueError("sorry, you lose")
Harald
Alain Ketterlin
> if (width == 0 and
> height == 0 and
> color == 'red' and
> emphasis == 'strong' or
> highlight > 100):
> raise ValueError("sorry, you lose")
I prefer to see the "and" at the beginning of continuation lines, and
usually group related items. I never mix operators without putting
explicit parentheses. Something like:
if ( width == 0 and height == 0
and color == 'red'
and ( emphasis == 'strong' or highlight > 100 ) ):
raise ValueError("sorry, you lose")
Anyway, choose your style and stick to it.
> The problem should be obvious -- it's not easy to see where the
> conditional ends and the statement begins since they have the same
> indentation. Part of the problem, I suppose, is that Emacs indents
> 'height' and the other lines in the conditional to 4 spaces (because
> of the parenthesis).
Emacs aligns "height" with "width", not with the parenthesis. You can
put as many spaces as you want before "(" or between "(" and "width",
and the following lines will follow. At least that's what happens with
my stock emacs-snapshot on ubuntu, with python.el.
If you use a backslashes at the end of line, emacs will double-indent
the following lines, but I think you said you prefer paretheses...
-- Alain.
Jean-Michel Pichavant
>
> height == 0 and
> color == 'red' and
> emphasis == 'strong' or
> highlight > 100):
> raise ValueError("sorry, you lose")
>
if (width ==0 and
' \\ // ' and height == 0 and
' \\// ' and color == 'red' and
' /OO\ ' and emphasis == 'strong' and
' \></ ' or highlight > 100):
raise ValueError("sorry, you lose")
Try doing this with spaces !! :p
JM
HH
wrote:
> HH <henri...@gmail.com> writes:
> > if (width == 0 and
> > height == 0 and
> > color == 'red' and
> > emphasis == 'strong' or
> > highlight > 100):
> > raise ValueError("sorry, you lose")
>
> I prefer to see the "and" at the beginning of continuation lines, and
> usually group related items. I never mix operators without putting
> explicit parentheses. Something like:
>
> if ( width == 0 and height == 0
> and color == 'red'
> and ( emphasis == 'strong' or highlight > 100 ) ):
> raise ValueError("sorry, you lose")
Thanks for all suggestions! I like this solution a lot.
I agree with your statement about mixed operators and explicit
parentheses -- expecially since the eye/brain parser often does it
wrong, and I believe you demonstrated that above...
In [29]: print(False and (False or True))
False
In [30]: print(False and False or True)
True
> If you use a backslashes at the end of line, emacs will double-indent
> the following lines, but I think you said you prefer paretheses...
Yes, I much prefer the parentheses -- partly because PEP-8 suggests it
but mostly because the escapes get lost too easily.
HH
Jonathan Hartley
wrote:
I've always liked this, or even:
if (
width == 0 and
height == 0 and
color == 'red' and
emphasis == 'strong' or
highlight > 100
):
raise ValueError("sorry, you lose")
but my co-workers have uniformly gone bananas whenever I try it.
Jean-Michel Pichavant
use what I described above, so I can understand why your co workers go
bananas :)
when it comes to extended conditions in if statement I prefer to write
something like
if self.haveLost():
raise ValueError("sorry, you lose")
It drastically improves the reading because it splits the notion of what
to do in which case, and how do you identify the cases (i.e. what should
I do when I've lost, and how do I know that I've lost). If you don't
want to pollute your upper namespace you can embed the function that way:
def foo():
width = 0
height = 0
color = 'red'
emphasis = 'strong'
def haveLost():
return not width and not height and color == 'red' and emphasis
=='strong'
if haveLost():
raise ValueError("sorry you lose")
It has the cool side effect to name your condition as well, that helps
debugging the condition *a lot*.
JM
Jonathan Hartley
> not use what I described above, so I can understand why your co
> workers go bananas :)
>
> when it comes to extended conditions in if statement I prefer to write
> something like
>
> if self.haveLost():
>
Good point.
+1 for naming the condition, hooray for self-documenting code.
Sometime last year at my workplace, we started referring to comments as
'lies', we now always try to use techniques like this instead of comments.
--
Jonathan Hartley Made of meat. http://tartley.com
tar...@tartley.com +44 7737 062 225 twitter/skype: tartley
Colin J. Williams
On 27-May-10 08:48 AM, Xavier Ho wrote:
> On 27 May 2010 22:22, HH <henr...@gmail.com
> <mailto:henr...@gmail.com>> wrote:
>
> if (width == 0 and
> height == 0 and
> color == 'red' and
> emphasis == 'strong' or
> highlight > 100):
> raise ValueError("sorry, you lose")
>
>
> I've gotta say - I've bumped into this problem before, and I'm sure many
> other have - this is a valid question. It just hasn't bothered me enough
> to ask...
>
> Correct me if I'm wrong, but I think the following is equivalent, and
> looks better. Although this won't fix all ugly cases in that problem..
>
> if (width, height, color, emphasis) == (0, 0, 'red', 'strong') or
> highlight > 100:
> raise ValueError("sorry, you lose")
>
> Cheers,
> Xav
but nobody commented.
Colin W.
john
wrote:
>
> >
> > if (width == 0 and
> > height == 0 and
> > color == 'red' and
> > emphasis == 'strong' or
> > highlight > 100):
> > raise ValueError("sorry, you lose")
> >
> >
> > I've gotta say - I've bumped into this problem before, and I'm sure many
> > other have - this is a valid question. It just hasn't bothered me enough
> > to ask...
> >
> > Correct me if I'm wrong, but I think the following is equivalent, and
> > looks better. Although this won't fix all ugly cases in that problem..
> >
> > if (width, height, color, emphasis) == (0, 0, 'red', 'strong') or
> > highlight > 100:
> > raise ValueError("sorry, you lose")
> >
> > Cheers,
> > Xav
>
> but nobody commented.
>
> Colin W.
Colin:
Sure, you can do it that way. IMO, though, the OP was wrong, and so
is the PEP. Source code is meant to communicate. So it must transmit
the correct information to the computer; it also must inform your
coworkers. That means that you have a responsibility to care what
they think, though you privately have your opinions. Another reason
the PEP is faulty in this circumstance is that a misplaced backslash,
or a missing one, is easily found and fixed. A misplaced parentheses,
or just one of a pair, will transform your source code into something
which may compile and then give faulty results: a disaster.
So keep it simple, and make it legible.
Yours,
John
Mark Lawrence
IMHO complete garbage, if your editor doesn't show misplaced or missing
parenthesis by highlighting you're using the wrong editor :)
Regards.
Mark Lawrence.
Colin J. Williams
> I prefer to just break such things into multiple lines. You're doing
> that already anyhow, it's not much of a speed hit, and it makes exactly
> what you're testing explicit. If I break a statement onto multiple
> lines I only use parenthesis, and that is as a last resort. In my
> opinion there's almost always some combination of variable assignments
> and lambda expressions that uses fewer lines and is clearer.
>
> is_correct_style = width == 0 and height == 0 and color == 'red'
> if (is_correct_style and emphasis == 'strong') or highlight > 100:
>
>
> On Sat, May 29, 2010 at 8:59 PM, Mark Lawrence <bream...@yahoo.co.uk
> <mailto:bream...@yahoo.co.uk>> wrote:
>
> On 30/05/2010 01:23, john wrote:
>
> wrote:
>
> On 28-May-10 05:54 AM, Jonathan Hartley wrote:
>
> On May 27, 1:57 pm, Jean-Michel
> Pichavant<jeanmic...@sequans.com
> missing parenthesis by highlighting you're using the wrong editor :)
>
> Regards.
>
> Mark Lawrence.
>
>
>
> http://mail.python.org/mailman/listinfo/python-list
>
>
Perhaps the arrangement below shows the matching a little better than
the Xav suggestion. The main point is that, to me, the tuple shows the
item by item matching better than a series of and clauses:
# tif.py
(width, height, color, emphasis)= 0, 0, 'red', 'strong'
highlight= 99
if (width, height, color, emphasis) == \
( 0, 0, 'red', 'strong') or highlight> 100:
raise ValueError("sorry, you lose")
Colin W.
Colin J. Williams
> I prefer to just break such things into multiple lines. You're doing
> that already anyhow, it's not much of a speed hit, and it makes exactly
> what you're testing explicit. If I break a statement onto multiple
> lines I only use parenthesis, and that is as a last resort. In my
> opinion there's almost always some combination of variable assignments
> and lambda expressions that uses fewer lines and is clearer.
>
> is_correct_style = width == 0 and height == 0 and color == 'red'
> if (is_correct_style and emphasis == 'strong') or highlight > 100:
>
>
> On Sat, May 29, 2010 at 8:59 PM, Mark Lawrence <bream...@yahoo.co.uk
> <mailto:bream...@yahoo.co.uk>> wrote:
>
> On 30/05/2010 01:23, john wrote:
>
> wrote:
>
> On 28-May-10 05:54 AM, Jonathan Hartley wrote:
>
> On May 27, 1:57 pm, Jean-Michel
> Pichavant<jeanmic...@sequans.com
> missing parenthesis by highlighting you're using the wrong editor :)
>
> Regards.
>
> Mark Lawrence.
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
Perhaps the arrangement below shows the matching a little better than
the Xav suggestion. The main point is that, to me, the tuple shows the
item by item matching better than a series of and clauses:
# tif.py
(width, height, color, emphasis)= 0, 0, 'red', 'strong'
highlight= 99
if (width, height, color, emphasis) == \
( 0, 0, 'red', 'strong') or highlight> 100:
raise ValueError("sorry, you lose")
Colin W.
Lie Ryan
> the Xav suggestion. The main point is that, to me, the tuple shows the
> item by item matching better than a series of and clauses:
>
> # tif.py
>
> (width, height, color, emphasis)= 0, 0, 'red', 'strong'
> highlight= 99
> if (width, height, color, emphasis) == \
> ( 0, 0, 'red', 'strong') or highlight> 100:
> raise ValueError("sorry, you lose")
How about:
all(a == b for a,b in ((width, 0), (height, 0), (color, 'red'),
(emphasis, 'strong'))))
Colin J. Williams
You need to add "or highlight > 100"
Giacomo Boffi
> if (width == 0 and
> height == 0 and
> color == 'red' and
> emphasis == 'strong' or
> highlight > 100):
> raise ValueError("sorry, you lose")
if (width == 0 and
height == 0 and
color == 'red' and
emphasis == 'strong' or
highlight > 100):
raise ValueError("sorry, you lose")
--
compro mobili vecchi - vendo mobili antichi
Aahz
Tim Chase <pytho...@tim.thechases.com> wrote:
>
>While it's not PEP material, I tend to use the coding standards I
>learned working for Computer Sciences Corporation (10 yrs ago, so
>things may have changed) that mandated 2 levels of indentation
>for continued lines, turning the above into
>
> if (width == 0 and
> height == 0 and
> color == 'red' and
> emphasis == 'strong' or
> highlight> 100):
> # or the closing "):" on this line,
> # aligned with the previous line
> raise ValueError("sorry, you lose")
+1
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
Greg Couch
To show another alternative, I like:
if (width == 0
and height == 0
and color == 'red'
and emphasis == 'strong'
or highlight > 100):
raise ValueError("sorry, you lose")
This works because and/or can not start an expression, so it is
obvious
that they continue the expression from the previous line. If I run
out
of room to put a full and/or clause on one line, then I'll indent the
subclause two levels.
-- Greg
Pete Forman
> I have a question about best practices when it comes to line
> wrapping/ continuation and indentation, specifically in the case of
> an if statement.
There are several good suggestions for formatting but no-one has
mentioned rewriting the code. Use a boolean variable to hold the
result of the condition and then the if statement is more readable.
--
Pete Forman -./\.-
West Sussex, UK -./\.-
http://petef.22web.net -./\.-
petef4...@gmail.com -./\.-
Jean-Michel Pichavant
> HH <henr...@gmail.com> writes:
>
> > I have a question about best practices when it comes to line
> > wrapping/ continuation and indentation, specifically in the case of
> > an if statement.
>
> There are several good suggestions for formatting but no-one has
> mentioned rewriting the code. Use a boolean variable to hold the
> result of the condition and then the if statement is more readable.
>
JM