6 ms·

Totally aside, but interesting: 80 characters was not an arbitrary limit, at least not directly. It was the size of the IBM standard punched card, and the term

Totally aside, but interesting: 80 characters was not an arbitrary limit, at least not directly. It was the size of the IBM standard punched card, and the terminals that succeeded them. Famously, versions of COBOL (FORTRAN too?) well into the 1990s would not even recognize input past column 80 even though it had long since graduated to text files. http://en.wikipedia.org/wiki/Punched_card http://en.wikipedia.org/wiki/Punched_card I still like to use 80 characters even today because it means I can fit two or even three pages of code side-by-side without wrapping. Great for merging.

mhd 14y ago
Especially when a tab isn't 8 spaces worth and you don't have a near useless level of indentation from the start (e.g. Java's "class" scope), I rarely found a problem with 80 (or 78) character limits. Quite the opposite, usually there's something "wrong" with code that exceeds that limit (a "code smell", as the hip kids like to say). Granted, quite often it's a "language smell", like Java or earlier C++'s verbose initialization forms and class terminology (AbstractFactoryImpl etc.). Other than that, it's often longer formulas or string building exercises, which usually could benefit from some temporary variables or printf-style format languages. If a statemenet has more than one operator and polysyllabic variable names, I generally prefer some variation of "let x be the overlong constant/class/descriptive name", e.g. "int x = DomainBasedStaticConfigurationSingleton.MAXIMUM_FROBNICATION_VALUE", instead of just adding up those monsters themselves. And being German, I'm actually quite used to silly compound nouns.
- icebraining 14y ago
  I don't know; I think it's fairly easy to hit that limit with some constructs like list comprehensions, particularly if they're inside a method (which cuts 12 characters with indention), yet remain readable. Something like: [person.name for person in people if person.country_of_origin == 'Netherlands' and person.age > 30] That's well above the limit, yet I still find it more readable than either a for loop that appends to a list or a map/filter (which would also have go through the list twice).
  - mhd 14y ago
    A longer/complicated list comprehension looks pretty similar to a (simple) SQL statement. And in both cases, there's really no reason why you couldn't put it on multiple lines, and they usually offer pretty good places to insert line breaks (e.g. "if" and "and" in your example).
    - icebraining 14y ago
      But does it really improve readability? Personally, I don't think it does - in neither case; unless it's really pathological, but then it shouldn't all be forced into a single list comprehension.
      - mhd 14y ago
        Well, it certainly doesn't help readability if parts of a line are cut off or the editor has to do an ugly linewrap, spoiling indentation. So as long as it doesn't significantly decrease readability for those corner cases and the benefits outweigh the drawbacks, I'm all for certain code conventions.

mhd 14y ago

Especially when a tab isn't 8 spaces worth and you don't have a near useless level of indentation from the start (e.g. Java's "class" scope), I rarely found a problem with 80 (or 78) character limits. Quite the opposite, usually there's something "wrong" with code that exceeds that limit (a "code smell", as the hip kids like to say). Granted, quite often it's a "language smell", like Java or earlier C++'s verbose initialization forms and class terminology (AbstractFactoryImpl etc.). Other than that, it's often longer formulas or string building exercises, which usually could benefit from some temporary variables or printf-style format languages. If a statemenet has more than one operator and polysyllabic variable names, I generally prefer some variation of "let x be the overlong constant/class/descriptive name", e.g. "int x = DomainBasedStaticConfigurationSingleton.MAXIMUM_FROBNICATION_VALUE", instead of just adding up those monsters themselves. And being German, I'm actually quite used to silly compound nouns.

icebraining 14y ago
I don't know; I think it's fairly easy to hit that limit with some constructs like list comprehensions, particularly if they're inside a method (which cuts 12 characters with indention), yet remain readable. Something like: [person.name for person in people if person.country_of_origin == 'Netherlands' and person.age > 30] That's well above the limit, yet I still find it more readable than either a for loop that appends to a list or a map/filter (which would also have go through the list twice).
- mhd 14y ago
  A longer/complicated list comprehension looks pretty similar to a (simple) SQL statement. And in both cases, there's really no reason why you couldn't put it on multiple lines, and they usually offer pretty good places to insert line breaks (e.g. "if" and "and" in your example).
  - icebraining 14y ago
    But does it really improve readability? Personally, I don't think it does - in neither case; unless it's really pathological, but then it shouldn't all be forced into a single list comprehension.
    - mhd 14y ago
      Well, it certainly doesn't help readability if parts of a line are cut off or the editor has to do an ugly linewrap, spoiling indentation. So as long as it doesn't significantly decrease readability for those corner cases and the benefits outweigh the drawbacks, I'm all for certain code conventions.