Graduate thesis on Python-related subject

[Benjamin.Altman]

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