Movatterモバイル変換

Graduate thesis on Python-related subject

• Previous message (by thread):Graduate thesis on Python-related subject
• Next message (by thread):Graduate thesis on Python-related subject
• Messages sorted by:[ date ][ thread ][ subject ][ author ]

"Benjamin.Altman" <benjamin.altman at noaa.gov> wrote in messagenews:3AE9AC80.36D8E0A at noaa.gov...> Potentially, there are less bugs to fix with less lines of code to bemaintained and> understood etc.>>hat at se-46.wpa.wtb.tue.nl wrote:>> > I consider #lines of code (in whatever definition of line) not veryuseful. In> > fact, in the past years, I have moved away from considering #linesanything> > near relevant.> > The real criterium of choosing a language is thus different. I haven'tfigured> > out what exactly, but concepts like 'readability' play an important roleimho.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-lineversion 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 opposedto 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 weare in exactly equivalent situations.  Why should the second form, whichis the preferred Python style of most programmers I think, be penalizedor considered twice as bug-prone?There ARE, however, measures of code size which are impervious to thesenon-complication-adding ways that lines can multiply.  But you need toget quite a bit more sophisticated than just line-counting...Alex

• Previous message (by thread):Graduate thesis on Python-related subject
• Next message (by thread):Graduate thesis on Python-related subject
• Messages sorted by:[ date ][ thread ][ subject ][ author ]