They may be a 'random' measure, but in practice it seems to be true. Obviously an if x: blah verses if x: blah is not what I was talking about. If it comes down to it you could say also: if \ acondition(foo): blah(bar) too. Alex Martelli wrote: > "Benjamin.Altman" <benjamin.altman at noaa.gov> wrote in message > news:3AE9AC80.36D8E0A at noaa.gov... > > Potentially, there are less bugs to fix with less lines of code to be > maintained and > > understood etc. > > > > hat at se-46.wpa.wtb.tue.nl wrote: > > > > > I consider #lines of code (in whatever definition of line) not very > useful. In > > > fact, in the past years, I have moved away from considering #lines > anything > > > near relevant. > > > The real criterium of choosing a language is thus different. I haven't > figured > > > out what exactly, but concepts like 'readability' play an important role > imho. > > To be precise, the *lines*, per se, are a rather random measurement. > There aren't going to be any more bugs, on average, lurking in a two-line > version of a statement: > a = b.c( > d) > than in the one-line equivalent: > a = b.c(d) > > OK, we could work around this one by thinking of logical lines as opposed > to physical ones. But still, consider: > if acondition(foo): blah(bar) > versus > if acondition(foo): > blah(bar) > these times the number of logical lines has really doubled, yet again we > are in exactly equivalent situations. Why should the second form, which > is the preferred Python style of most programmers I think, be penalized > or considered twice as bug-prone? > > There ARE, however, measures of code size which are impervious to these > non-complication-adding ways that lines can multiply. But you need to > get quite a bit more sophisticated than just line-counting... > > Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4