Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #25930
| Newsgroups | comp.lang.python |
|---|---|
| Date | 2012-07-23 14:48 -0700 |
| References | <500A5B47.1060805@freenet.de> <mailman.2370.1342861455.4697.python-list@python.org> |
| Subject | Re: Basic question about speed/coding style/memory |
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
| Message-ID | <mailman.2505.1343080119.4697.python-list@python.org> (permalink) |
Chris Angelico於 2012年7月21日星期六UTC+8下午5時04分12秒寫道: > On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers <janpeterr@freenet.de> wrote: > > Block > > #---------------------------------- > > if statemente_true: > > doSomething() > > else: > > doSomethingElseInstead() > > > > #---------------------------------- > > This means, to me, that the two options are peers - you do this or you do that. > > > versus this block: > > #---------------------------------- > > if statement_true: > > doSomething() > > return > > > > doSomethingElseInstead() > > > > #---------------------------------- > > This would be for an early abort. Don't bother doing most of this > function's work, just doSomething. Might be an error condition, or > perhaps an optimized path. > > Definitely for error conditions, I would use the second option. The > "fail and bail" notation keeps the entire error handling in one place: > > def func(x,y,z): > if x<0: > y+=5 > return > if y<0: > raise PEBKAC("There's an idiot here somewhere") > # ... do the rest of the work > This is the caller responsible style when passing parameters to functions. Checking types of parameters both in the caller and the callee does slow down a little bit. > Note the similarity between the control structures. Raising an > exception immediately terminates processing, without polluting the > rest of the function with an unnecessary indentation level. Early > aborting through normal function return can do the same thing. > > But this is purely a matter of style. I don't think there's any > significance in terms of processing time or memory usage, and even if > there is, it would be dwarfed by considerations of readability. Make > your code look like what it's doing, and let the execution take care > of itself. > > ChrisA
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Basic question about speed/coding style/memory Chris Angelico <rosuav@gmail.com> - 2012-07-21 19:04 +1000 Re: Basic question about speed/coding style/memory 88888 Dihedral <dihedral88888@googlemail.com> - 2012-07-23 14:48 -0700 Re: Basic question about speed/coding style/memory 88888 Dihedral <dihedral88888@googlemail.com> - 2012-07-23 14:48 -0700
csiph-web