Movatterモバイル変換
[0]ホーム
Graduate thesis on Python-related subject
Benjamin.Altmanbenjamin.altman at noaa.gov
Mon Apr 30 09:43:58 EDT 2001
They may be a 'random' measure, but in practice it seems to be true. Obviouslyan if x: blahverses if x: blahis 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
More information about the Python-listmailing list
[8]ページ先頭