5 ms·

The 80 column “rule” also discourages the use of descriptive naming, which IMO is far more important to readability than short lines. Also 80 columns is near i

The 80 column “rule” also discourages the use of descriptive naming, which IMO is far more important to readability than short lines. Also 80 columns is near impossible to adhere to for more verbose language.

skrtskrt 6y ago
For both Python and Go I use descriptive (often long) names and ~90-char line limit, and use linebreaks liberally to reconcile the two
bjourne 6y ago
Descriptive naming usually isn't. E=m*c^2 or objectEnergyInJoule = massOfObjectInKilograms * speedOfLightInVacuum^2 ?
- DangitBobby 6y ago
  Now imagine that you're not looking at a famous equation and you tell me which one you would rather have to sus out the intention of. a = b/c or numApples = numBananas/apple BananaConversionRate
  - bjourne 6y ago
    The first one, no question about it.
    - kazinator 6y ago
      Yes. We would want the descriptive names for identifiers which have broad scope, but short names for the local variables that work with them. I would rather give a function the descriptive name in such a way that the parameters can then be given trivial, mnemonic names. Strawmannish example: incrementAccountBalance(a, n) { ... } The descriptive function name gives away what a and n are, so it is unhelpful to make this: incrementAccountBalance(account, amountToIncrementBy) Reasonable middle ground: incrementAccountBalance(acct, delta)
      - spideymans 6y ago
        With incrementAccountBalance(a, n), it's impossible to tell exactly what each argument is from the function signature alone. Of course I could assume that a = account and n = amount to increment by, but that's nothing more than an assumption, which only invites inevitable bugs. Alternatively I could look at the function body, and try to figure out what's going on, but that's time wasted that could be spent more productively. Further, non-descriptive naming often assumes that the programmer reading and modifying the code has domain-specific knowledge. That might be true of mid level or senior engineers have have been with a particular company for years, but the new grad coming into a financial services company (a field he has no training or familiarity with) will have no idea what "a" or "b" means. I was in that position, and the descriptive naming absolutely would have helped me to learn and become productive with the codebase faster. I'd say that your reasonable middle ground would be the best practice.
    - DangitBobby 6y ago
      Opposite of my choice of which I also have no question.
Viliam1234 6y ago
> Also 80 columns is near impossible to adhere to for more verbose language. Not if you use Unicode (and Chinese language).

skrtskrt 6y ago

For both Python and Go I use descriptive (often long) names and ~90-char line limit, and use linebreaks liberally to reconcile the two

bjourne 6y ago

Descriptive naming usually isn't. E=m*c^2 or objectEnergyInJoule = massOfObjectInKilograms * speedOfLightInVacuum^2 ?

DangitBobby 6y ago
Now imagine that you're not looking at a famous equation and you tell me which one you would rather have to sus out the intention of. a = b/c or numApples = numBananas/apple BananaConversionRate
- bjourne 6y ago
  The first one, no question about it.
  - kazinator 6y ago
    Yes. We would want the descriptive names for identifiers which have broad scope, but short names for the local variables that work with them. I would rather give a function the descriptive name in such a way that the parameters can then be given trivial, mnemonic names. Strawmannish example: incrementAccountBalance(a, n) { ... } The descriptive function name gives away what a and n are, so it is unhelpful to make this: incrementAccountBalance(account, amountToIncrementBy) Reasonable middle ground: incrementAccountBalance(acct, delta)
    - spideymans 6y ago
      With incrementAccountBalance(a, n), it's impossible to tell exactly what each argument is from the function signature alone. Of course I could assume that a = account and n = amount to increment by, but that's nothing more than an assumption, which only invites inevitable bugs. Alternatively I could look at the function body, and try to figure out what's going on, but that's time wasted that could be spent more productively. Further, non-descriptive naming often assumes that the programmer reading and modifying the code has domain-specific knowledge. That might be true of mid level or senior engineers have have been with a particular company for years, but the new grad coming into a financial services company (a field he has no training or familiarity with) will have no idea what "a" or "b" means. I was in that position, and the descriptive naming absolutely would have helped me to learn and become productive with the codebase faster. I'd say that your reasonable middle ground would be the best practice.
  - DangitBobby 6y ago
    Opposite of my choice of which I also have no question.

Viliam1234 6y ago

> Also 80 columns is near impossible to adhere to for more verbose language. Not if you use Unicode (and Chinese language).