Prev: type error raise
Next: Minor annoyances with properties
From: Jean-Michel Pichavant on 28 May 2010 06:34 Jonathan Hartley wrote: > On May 27, 1:57 pm, Jean-Michel Pichavant <jeanmic...(a)sequans.com> > wrote: > >> HH wrote: >> >>> I have a question about best practices when it comes to line wrapping/ >>> 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 >>> >> One possible solution >> >> if ( >> width == 0 and >> height == 0 and >> color == 'red' and >> emphasis == 'strong' or >> highlight > 100 >> ): >> raise ValueError("sorry, you lose") >> >> JM >> > > 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. > I tried to give a layout that fits the OP way of doing, but I would 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(): 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
From: Jonathan Hartley on 28 May 2010 06:48 On 28/05/2010 11:34, Jean-Michel Pichavant wrote: > Jonathan Hartley wrote: >> On May 27, 1:57 pm, Jean-Michel Pichavant <jeanmic...(a)sequans.com> >> wrote: >>> HH wrote: >>>> I have a question about best practices when it comes to line wrapping/ >>>> 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 >>> One possible solution >>> >>> if ( >>> width == 0 and >>> height == 0 and >>> color == 'red' and >>> emphasis == 'strong' or >>> highlight > 100 >>> ): >>> raise ValueError("sorry, you lose") >>> >>> JM >> >> 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. > I tried to give a layout that fits the OP way of doing, but I would > 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(): > raise ValueError("sorry, you lose") > > It drastically improves the reading 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 tartley(a)tartley.com +44 7737 062 225 twitter/skype: tartley
From: Colin J. Williams on 28 May 2010 13:37 On 28-May-10 05:54 AM, Jonathan Hartley wrote: > On May 27, 1:57 pm, Jean-Michel Pichavant<jeanmic...(a)sequans.com> > wrote: >> HH wrote: >>> I have a question about best practices when it comes to line wrapping/ >>> 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 >> >> One possible solution >> >> if ( >> width == 0 and >> height == 0 and >> color == 'red' and >> emphasis == 'strong' or >> highlight> 100 >> ): >> raise ValueError("sorry, you lose") >> >> JM > > 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. I liked: On 27-May-10 08:48 AM, Xavier Ho wrote: > On 27 May 2010 22:22, HH <henrikho(a)gmail.com > <mailto:henrikho(a)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.
From: john on 29 May 2010 20:23 On May 28, 10:37 am, "Colin J. Williams" <cjwilliam...(a)gmail.com> wrote: > On 28-May-10 05:54 AM, Jonathan Hartley wrote: > > > On May 27, 1:57 pm, Jean-Michel Pichavant<jeanmic...(a)sequans.com> > > wrote: > >> HH wrote: > >>> I have a question about best practices when it comes to line wrapping/ > >>> 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 > > >> One possible solution > > >> if ( > >> width == 0 and > >> height == 0 and > >> color == 'red' and > >> emphasis == 'strong' or > >> highlight> 100 > >> ): > >> raise ValueError("sorry, you lose") > > >> JM > > > 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. > > I liked: > > On 27-May-10 08:48 AM, Xavier Ho wrote: > > On 27 May 2010 22:22, HH <henri...(a)gmail.com > <mailto:henri...(a)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. 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
From: Mark Lawrence on 29 May 2010 20:59 On 30/05/2010 01:23, john wrote: > On May 28, 10:37 am, "Colin J. Williams"<cjwilliam...(a)gmail.com> > wrote: >> On 28-May-10 05:54 AM, Jonathan Hartley wrote: >> >>> On May 27, 1:57 pm, Jean-Michel Pichavant<jeanmic...(a)sequans.com> >>> wrote: >>>> HH wrote: >>>>> I have a question about best practices when it comes to line wrapping/ >>>>> 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 >> >>>> One possible solution >> >>>> if ( >>>> width == 0 and >>>> height == 0 and >>>> color == 'red' and >>>> emphasis == 'strong' or >>>> highlight> 100 >>>> ): >>>> raise ValueError("sorry, you lose") >> >>>> JM >> >>> 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. >> >> I liked: >> >> On 27-May-10 08:48 AM, Xavier Ho wrote: >> > On 27 May 2010 22:22, HH<henri...(a)gmail.com> <mailto:henri...(a)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. > > 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 IMHO complete garbage, if your editor doesn't show misplaced or missing parenthesis by highlighting you're using the wrong editor :) Regards. Mark Lawrence.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: type error raise Next: Minor annoyances with properties |