13 ms·

I disagree with a lot of this, but I'll focus on the worst offender. The rule against identifiers shorter than 8 characters specifically disallows `name', which

by nv-vn 10y ago

I disagree with a lot of this, but I'll focus on the worst offender. The rule against identifiers shorter than 8 characters specifically disallows `name', which makes absolutely no sense to me. This particular word says a lot, and it can easily have its context implied with no problems. Example, if we're working on a database that stores people's personal information, it's easy to guess what `name' means. If we're processing HTML forms, again, name has a very clear meaning here. We could also use it to describe syntax (i.e. identifiers, or as an alternate term for JSON-style keys). If I tried for another couple minutes I'm sure I could think of hundreds of use cases for that identifier with a clear context. What I don't understand, though, is the exceptions they list. Such as "c, d, e ... in, inOut, ...". These, on the other hand, have very few contexts where they're at all clear. What happened to the whole stigma against 1-char identifiers? How could a 7-char identifier be any worse than a 1-char identifier? This whole rule seems like nonsense.

hellofunk 10y ago
I would argue that "name" by itself is actually quite a bad name. What is it naming? It should "firstName" or "databaseName", etc. I have learned over many years that longer, highly readable and descriptive names make life extremely easier in the long run, at the expense of a few extra characters to type.
- madeofpalk 10y ago
  Surely the context it's in would help you understand whether its referring to a person or a database?
  - hellofunk 10y ago
    So many unreadable and confusing code bases exist precisely because people made that assumption. For example, in the case of "name" there are typically many different things that need a "name" in the same context. First name, last name, etc. "name" by itself (and other short names) is honestly asking for lots of headaches in the long run.
    - jstimpfle 10y ago
      The CRUD database tables I make usually have "id" and "name" columns. "name" is always a human-readable descriptive string (few words). No need to have a more specific name for what "name" is. If you write SQL, you can disambiguate by table name prefix. If you iterate over result sets for example in python, you can easily be more specific on tuple destructuring time ("for personName, carName in ..."). When defining a table "Person", I consider it bad style to prefix all column names with "person". Btw this overzealous disambiguation falls flat as soon you do a self-join.
      - hellofunk 10y ago
        A DB has a lot more obvious and strict context than a file of source code, and the law of demeter typically doesn't affect DB contexts as much as it does code, in practice. In real code, it's unwise to expect the reader to study context just to parse a name.
        jstimpfle 10y ago
        Are you agreeing with me here? I think so but can't tell for sure...
        hellofunk 10y ago
        I'm saying that a DB's organization is not the same as that of source code, and that surrounding context is a fundamental part of working with a DB and reading its layout, so perhaps the naming rules can be relaxed a bit in some cases.
onion2k 10y ago
If you're processing an HTML form then 'name' could be the form name attribute, the input element name attribute, the person's name, the person's username, the person's identifier within the application or database, and so on. Try reading some badly written PHP form handling code where the logic and the HTML are in the same script and you see this precise problem.
- M2Ys4U 10y ago
  Surname is only seven letters and it doesn't suffer those problems
  - zeta0134 10y ago
    It suffers a different problem though: Name implies your given name, possibly including your family name. Surname is much more specific (family name only) and thus not suitable in any case where that's not what you meant. This is not an easy problem to solve. For every "easy" example of a good name, one readily encounters an easy counterexample that renders the name ambiguous or unfit for a particular purpose. Names must necessarily include context to be meaningful. If "name" is an unambiguous identifier in your scope and it's obvious what it does, great! Don't fix what isn't broken. But when you catch ambiguity or uncertainty, revisit the code, so future developers have an easier time understanding what you meant.
    - TeMPOraL 10y ago
      > It suffers a different problem though: Name implies your given name, possibly including your family name. Surname is much more specific (family name only) and thus not suitable in any case where that's not what you meant. And this digs out a tangential problem - that often, "name" is as specific as you can get (or at least as specific as you should get) - http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b....
- barrkel 10y ago
  This is definitely a problem when you mix different semantic concerns in one level of code. Doctor, it hurts when ...
junke 10y ago
Yes, many useful names are short: point, input, output, x, y, z, origin, r, g, b, alpha, color, vector, pi, string, file, buffer, open, close, print, format, copy, move, list, load, run, id, pop, push, stack, context, env, user, draw, update, refresh. Also, notice how R, G, and B have a very clear meaning when put near "color"? Context is a thing our brain manages very well.
- vorg 10y ago
  Many of those short names are keywords (or pre-defined identifiers) in many programming languages, e.g. string, close, print, copy in Go. Having to use another name instead can also be difficult.
  - junke 10y ago
    Poetry time: (let ((copy (copy-list list))) (list copy 'copy 'let)) A 13 syllabic verse (7+6, with caesura) (but yes, you are right)
    - fiddlerwoaroof 10y ago
      FWIW, I never have really found the ambiguity caused by using the same symbol as both a variable and a function to be a readability problem: I think people are generally pretty good at things like noun/verb ambiguity and so this kind of ambiguity sort of "clicks" with us. What has bitten me many times is accidentally overwriting a builtin function like max or len in python and then scratching my head about the strange errors that result from this.
      - junke 10y ago
        Overwriting is not so much a problem of naming than one of dynamic updates: some environments do actually display a warning when you change a global binding, which helps.
        fiddlerwoaroof 10y ago
stevedonovan 10y ago
I like the rule-of-thumb that short identifiers are fine if their context is limited in length - particularly if proper lexical scoping is supported. Humans do context very well, and imposing some arbitrary length limit ignores this.
- edblarney 10y ago
  This is important. When you're inside a function, dealing with very limited scoped variables, people get that. People also 'get' attributes of classes and can grasp that context. You know what's rational - that the 'length' of an array is just called 'length' :) Anything else would be missing the point.
coldtea 10y ago
>The rule against identifiers shorter than 8 characters specifically disallows `name', which makes absolutely no sense to me. This particular word says a lot, and it can easily have its context implied with no problems. Example, if we're working on a database that stores people's personal information, it's easy to guess what `name' means. Is it "first name", "last name" or "full name"?
ape4 10y ago
'name' is the one worst variable names possible. Its like calling your program 'program', your function 'function'. There is always a better choice.
- lallysingh 10y ago
  Depends on the context. If other vars are 'addess' and 'phoneNumber', 'name' looks pretty reasonable.
  - deleted 10y ago
    [deleted]
  - masklinn 10y ago
    Hardly. Is it a person's full name? legal name? first name? last name? nick name? desired call name? a company name? the name (alias) of the stored address?
    - gohrt 10y ago
      legal name in which country? name order varies between UK and China. What's a "call"? Whose company? what kind of address? Following this line of thinking, communication is impossible because everything is ambiguous.
      - masklinn 10y ago
        > Following this line of thinking, communication is impossible because everything is ambiguous. And making everything as ambiguous as possible makes communication easier… how?
    - TeMPOraL 10y ago
      If you're digging into that specific meaning of the word "name" (as a property of a person), you're likely doing something wrong: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...

by nv-vn 10y ago

hellofunk 10y ago

I would argue that "name" by itself is actually quite a bad name. What is it naming? It should "firstName" or "databaseName", etc. I have learned over many years that longer, highly readable and descriptive names make life extremely easier in the long run, at the expense of a few extra characters to type.

madeofpalk 10y ago
Surely the context it's in would help you understand whether its referring to a person or a database?
- hellofunk 10y ago
  So many unreadable and confusing code bases exist precisely because people made that assumption. For example, in the case of "name" there are typically many different things that need a "name" in the same context. First name, last name, etc. "name" by itself (and other short names) is honestly asking for lots of headaches in the long run.
  - jstimpfle 10y ago
    The CRUD database tables I make usually have "id" and "name" columns. "name" is always a human-readable descriptive string (few words). No need to have a more specific name for what "name" is. If you write SQL, you can disambiguate by table name prefix. If you iterate over result sets for example in python, you can easily be more specific on tuple destructuring time ("for personName, carName in ..."). When defining a table "Person", I consider it bad style to prefix all column names with "person". Btw this overzealous disambiguation falls flat as soon you do a self-join.
    - hellofunk 10y ago
      A DB has a lot more obvious and strict context than a file of source code, and the law of demeter typically doesn't affect DB contexts as much as it does code, in practice. In real code, it's unwise to expect the reader to study context just to parse a name.
      - jstimpfle 10y ago
        Are you agreeing with me here? I think so but can't tell for sure...
        hellofunk 10y ago
        I'm saying that a DB's organization is not the same as that of source code, and that surrounding context is a fundamental part of working with a DB and reading its layout, so perhaps the naming rules can be relaxed a bit in some cases.

onion2k 10y ago

If you're processing an HTML form then 'name' could be the form name attribute, the input element name attribute, the person's name, the person's username, the person's identifier within the application or database, and so on. Try reading some badly written PHP form handling code where the logic and the HTML are in the same script and you see this precise problem.

M2Ys4U 10y ago
Surname is only seven letters and it doesn't suffer those problems
- zeta0134 10y ago
  It suffers a different problem though: Name implies your given name, possibly including your family name. Surname is much more specific (family name only) and thus not suitable in any case where that's not what you meant. This is not an easy problem to solve. For every "easy" example of a good name, one readily encounters an easy counterexample that renders the name ambiguous or unfit for a particular purpose. Names must necessarily include context to be meaningful. If "name" is an unambiguous identifier in your scope and it's obvious what it does, great! Don't fix what isn't broken. But when you catch ambiguity or uncertainty, revisit the code, so future developers have an easier time understanding what you meant.
  - TeMPOraL 10y ago
    > It suffers a different problem though: Name implies your given name, possibly including your family name. Surname is much more specific (family name only) and thus not suitable in any case where that's not what you meant. And this digs out a tangential problem - that often, "name" is as specific as you can get (or at least as specific as you should get) - http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b....
barrkel 10y ago
This is definitely a problem when you mix different semantic concerns in one level of code. Doctor, it hurts when ...

junke 10y ago

Yes, many useful names are short: point, input, output, x, y, z, origin, r, g, b, alpha, color, vector, pi, string, file, buffer, open, close, print, format, copy, move, list, load, run, id, pop, push, stack, context, env, user, draw, update, refresh. Also, notice how R, G, and B have a very clear meaning when put near "color"? Context is a thing our brain manages very well.

vorg 10y ago
Many of those short names are keywords (or pre-defined identifiers) in many programming languages, e.g. string, close, print, copy in Go. Having to use another name instead can also be difficult.
- junke 10y ago
  Poetry time: (let ((copy (copy-list list))) (list copy 'copy 'let)) A 13 syllabic verse (7+6, with caesura) (but yes, you are right)
  - fiddlerwoaroof 10y ago
    FWIW, I never have really found the ambiguity caused by using the same symbol as both a variable and a function to be a readability problem: I think people are generally pretty good at things like noun/verb ambiguity and so this kind of ambiguity sort of "clicks" with us. What has bitten me many times is accidentally overwriting a builtin function like max or len in python and then scratching my head about the strange errors that result from this.
    - junke 10y ago
      Overwriting is not so much a problem of naming than one of dynamic updates: some environments do actually display a warning when you change a global binding, which helps.
      - fiddlerwoaroof 10y ago

stevedonovan 10y ago

I like the rule-of-thumb that short identifiers are fine if their context is limited in length - particularly if proper lexical scoping is supported. Humans do context very well, and imposing some arbitrary length limit ignores this.

edblarney 10y ago
This is important. When you're inside a function, dealing with very limited scoped variables, people get that. People also 'get' attributes of classes and can grasp that context. You know what's rational - that the 'length' of an array is just called 'length' :) Anything else would be missing the point.

coldtea 10y ago

>The rule against identifiers shorter than 8 characters specifically disallows `name', which makes absolutely no sense to me. This particular word says a lot, and it can easily have its context implied with no problems. Example, if we're working on a database that stores people's personal information, it's easy to guess what `name' means. Is it "first name", "last name" or "full name"?

ape4 10y ago

'name' is the one worst variable names possible. Its like calling your program 'program', your function 'function'. There is always a better choice.

lallysingh 10y ago
Depends on the context. If other vars are 'addess' and 'phoneNumber', 'name' looks pretty reasonable.
- deleted 10y ago
  [deleted]
- masklinn 10y ago
  Hardly. Is it a person's full name? legal name? first name? last name? nick name? desired call name? a company name? the name (alias) of the stored address?
  - gohrt 10y ago
    legal name in which country? name order varies between UK and China. What's a "call"? Whose company? what kind of address? Following this line of thinking, communication is impossible because everything is ambiguous.
    - masklinn 10y ago
      > Following this line of thinking, communication is impossible because everything is ambiguous. And making everything as ambiguous as possible makes communication easier… how?
  - TeMPOraL 10y ago
    If you're digging into that specific meaning of the word "name" (as a property of a person), you're likely doing something wrong: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...