4 ms·

I like a lot of the concepts, but I'm dubious about terse naming. The long e-mail example simplifies "msg" to "m", for example. Now, while I would agree that ve

I like a lot of the concepts, but I'm dubious about terse naming. The long e-mail example simplifies "msg" to "m", for example. Now, while I would agree that veryLongVariableNames can get tedious and annoying, and while I'm also in favor of standardized generic loop indexes (i,j,etc..), I think this may go to the other extreme. I could see going from "message" -> "msg", perhaps, but I'm not sure "msg" -> "m" is a win. Why is saving two characters that important?

mynameishere 18y ago
I could see going from "message" -> "msg" There are dozens of possible abbreviations for "message" but only one correct spelling of "message". Abbreviating a word forces the reader to remember both what it is, and what its abbreviation is. One of the seldom-mentioned gifts that java has given the world is killing the horrendous C practice of insane abbreviations. I can't tell you how many times I've had to look up itoa(). It just wouldn't stay in my brain. But I guess it keeps my teletype's ink from running out too fast.
- AndyKelley 18y ago
  I think once you load the context of any given program into your head, the variable names become irrelevant. Programming on my TI-83 in elementary school, all I got was A-Z, but when I spent every class making a checkers game in TI-basic, I never forgot that C was the X-dimension of the current selection, Q was the number of black pieces left, and matrix [B] was the last saved game
- msluyter 18y ago
  While it's true that there are many abbreviations of "message," surely some are inherently easier to cognitively process than others. Compare: "eag", "sg", "msa" -- randomly chosen letters (in orig order) vs. "age", "meg","mag" -- purposefully misleading substrings, vs "msg", "mes", "mssg" -- closer to semantic content My point is not so much to quibble, but to suggest that we may have something to learn from cognitive psychology on the subject. Does anyone recall the recent study that showed taht as lnog as the fsrit and lsat lteters of wrods wree the smae, poplee culod gnerlaly mkae out the manenig? (whew! hard to type that.) This suggests to me that at the very least, retaining the first letter is important, and possibly the last as well. My qualm about single letter variable names is that they may require more "lookup time" (on average) because so much of the semantic content has been stripped from the name. I'm curious if anyone has actually researched this? I'm only theorizing here.
- ericb 18y ago
  I'd upvote you twice if I could. You don't even have to look at the screen if you follow a consistent rule of not abbreviating. If you do abbreviate, does your buddy use the same scheme? Consistently? Why optimize for typing speed when memory and "variable lookups" are the bottleneck?
- scott_s 18y ago
  I go for abbreviations that are pronounceable - but I do try to abbreviate. My soft rule is six characters or more. I understand your concern, but I consider horizontal space a resource. There's a point at which long names just add to the clutter and get in the way of the concepts.
bmj 18y ago
The Pike essay linked elsewhere in the comments puts it this way: [snip] Finally, I prefer minimumlength but maximuminformation names, and then let the context fill in the rest. Globals, for instance, typically have little context when they are used, so their names need to be relatively evocative. Thus I say maxphysaddr (not MaximumPhysicalAddress) for a global variable, but np not NodePointer for a pointer locally defined and used. This is largely a matter of taste, but taste is relevant to clarity. [/snip] One could argue that the variable m, within the context of that method, is easily understood as a Message. All that said, I'd prefer msg--two extra tokens per line isn't really going to clutter the code, and likely make it easier for other programmers to understand what's going on.
a-priori 18y ago
I agree. With IDE auto-completion, measuring characters become less meaningful. Using tokens would be better.
- alexfarran 18y ago
  IDEs can't read your code for you. So VeryLongIdentifiers should still be replaced with something that's easier to scan.
  - Hexstream 18y ago
    As far as I'm concerned, VeryLongIdentifiers are easier to scan (for small values of "very"). VeryLongIdentifier is actually a reasonable length, though any more than this does get unwieldy.
hassy 18y ago
I found that terse naming has several advantages: * Most obvious one: it's easier to type. Especially in Erlang - the language I write most code in these days, where variables must start with a capital letter. The fewer times I have to reach for the shift key to make a capital (if I used CamelCase) or to make an underscore, the better. * Short names help you fit code in 80 columns. * Terse variable names force you to pay close attention and make no assumptions about what's inside that variable. Also, I found that a short name + an inline comment to explain what's there works better than an overly descriptive name. I do the same for function names too, with the exception of public functions -- those get proper names. So I'd call the public function `integer_to_string` but if I were to use it only privately, it'd be `itostr`.
- ericb 18y ago
  itostr takes time to mentally process (or pronounce), if I had to read your code. integer_to_string takes no effort and can't be confused. To make the point: itostr - itoaster? itostr - int to stream? itostr - internationalize OString? itostr - The string representation for indium tin oxide?
  - msluyter 18y ago
    No, it's Iguana to Stretchpants.
  - hassy 18y ago
    > itostr takes time to mentally process (or pronounce), if I had to read your code. integer_to_string takes no effort and can't be confused. The idea is that the first time you saw `itostr` you'd do something like this: * Jump to the definition of `itostr` (a couple of keypresses in Emacs). * Read the Edoc comment for the function ("Convert integer to string"). * Jump back to where you were (one key combo). Sure, if the function was named `integer_to_string` you wouldn't have to do the above. But this was a trivial example. Many functions would take more than three words to describe what they are doing precisely, especially when your functions are granular and do exactly one thing. This can quickly lead to long lines, which I find hard to read and ugly. At the end of the day, it's all down to personal preferences and style. I like things this way, and you like them the other. It's just the way it is, and there are arguments for both approaches. For me, the benefits of terse naming outweigh its disadvantages, and the advantages of long descriptive names.
rsheridan6 18y ago
As an emacs user who is only slightly familiar with vim, I've wondered whether this may reflect a weakness of vim. With emacs + SLIME or even just dabbrev (included in emacs by default), you don't type the whole word anyway - you type an abbreviation and expand it. Does vim not have an equivalent capability? If not, that would explain why pg thinks abbreviated names are a win.
- astine 18y ago
  Word completion is available and it would be possible to implement something like this in vim script. But, as far as I know, vim users don't typically use this; it doesn't generally fit in with the philosophy of the editor.
  - jrockway 18y ago
    So you let the philosophy of your editor get in the way of writing good code? Sounds like a plan...
    - astine 18y ago
      lol. No, you let it get in the way of extending your editor. You can write good code without abbreviation expansions. Vi hardliners would see it as unnecessary feature creep as it is rather complicated and doesn't fit in as well as other commands.
- tokipin 18y ago
  yes, there's abbreviation expansion. i do well enough with keyword completion though
- jcl 18y ago
  http://www.vim.org/htmldoc/map.html#Abbreviations http://www.vim.org/htmldoc/map.html#Abbreviations

mynameishere 18y ago

I could see going from "message" -> "msg" There are dozens of possible abbreviations for "message" but only one correct spelling of "message". Abbreviating a word forces the reader to remember both what it is, and what its abbreviation is. One of the seldom-mentioned gifts that java has given the world is killing the horrendous C practice of insane abbreviations. I can't tell you how many times I've had to look up itoa(). It just wouldn't stay in my brain. But I guess it keeps my teletype's ink from running out too fast.

AndyKelley 18y ago
I think once you load the context of any given program into your head, the variable names become irrelevant. Programming on my TI-83 in elementary school, all I got was A-Z, but when I spent every class making a checkers game in TI-basic, I never forgot that C was the X-dimension of the current selection, Q was the number of black pieces left, and matrix [B] was the last saved game
msluyter 18y ago
While it's true that there are many abbreviations of "message," surely some are inherently easier to cognitively process than others. Compare: "eag", "sg", "msa" -- randomly chosen letters (in orig order) vs. "age", "meg","mag" -- purposefully misleading substrings, vs "msg", "mes", "mssg" -- closer to semantic content My point is not so much to quibble, but to suggest that we may have something to learn from cognitive psychology on the subject. Does anyone recall the recent study that showed taht as lnog as the fsrit and lsat lteters of wrods wree the smae, poplee culod gnerlaly mkae out the manenig? (whew! hard to type that.) This suggests to me that at the very least, retaining the first letter is important, and possibly the last as well. My qualm about single letter variable names is that they may require more "lookup time" (on average) because so much of the semantic content has been stripped from the name. I'm curious if anyone has actually researched this? I'm only theorizing here.
ericb 18y ago
I'd upvote you twice if I could. You don't even have to look at the screen if you follow a consistent rule of not abbreviating. If you do abbreviate, does your buddy use the same scheme? Consistently? Why optimize for typing speed when memory and "variable lookups" are the bottleneck?
scott_s 18y ago
I go for abbreviations that are pronounceable - but I do try to abbreviate. My soft rule is six characters or more. I understand your concern, but I consider horizontal space a resource. There's a point at which long names just add to the clutter and get in the way of the concepts.

bmj 18y ago

The Pike essay linked elsewhere in the comments puts it this way: [snip] Finally, I prefer minimumlength but maximuminformation names, and then let the context fill in the rest. Globals, for instance, typically have little context when they are used, so their names need to be relatively evocative. Thus I say maxphysaddr (not MaximumPhysicalAddress) for a global variable, but np not NodePointer for a pointer locally defined and used. This is largely a matter of taste, but taste is relevant to clarity. [/snip] One could argue that the variable m, within the context of that method, is easily understood as a Message. All that said, I'd prefer msg--two extra tokens per line isn't really going to clutter the code, and likely make it easier for other programmers to understand what's going on.

a-priori 18y ago

I agree. With IDE auto-completion, measuring characters become less meaningful. Using tokens would be better.

alexfarran 18y ago
IDEs can't read your code for you. So VeryLongIdentifiers should still be replaced with something that's easier to scan.
- Hexstream 18y ago
  As far as I'm concerned, VeryLongIdentifiers are easier to scan (for small values of "very"). VeryLongIdentifier is actually a reasonable length, though any more than this does get unwieldy.

hassy 18y ago

I found that terse naming has several advantages: * Most obvious one: it's easier to type. Especially in Erlang - the language I write most code in these days, where variables must start with a capital letter. The fewer times I have to reach for the shift key to make a capital (if I used CamelCase) or to make an underscore, the better. * Short names help you fit code in 80 columns. * Terse variable names force you to pay close attention and make no assumptions about what's inside that variable. Also, I found that a short name + an inline comment to explain what's there works better than an overly descriptive name. I do the same for function names too, with the exception of public functions -- those get proper names. So I'd call the public function `integer_to_string` but if I were to use it only privately, it'd be `itostr`.

ericb 18y ago
itostr takes time to mentally process (or pronounce), if I had to read your code. integer_to_string takes no effort and can't be confused. To make the point: itostr - itoaster? itostr - int to stream? itostr - internationalize OString? itostr - The string representation for indium tin oxide?
- msluyter 18y ago
  No, it's Iguana to Stretchpants.
- hassy 18y ago
  > itostr takes time to mentally process (or pronounce), if I had to read your code. integer_to_string takes no effort and can't be confused. The idea is that the first time you saw `itostr` you'd do something like this: * Jump to the definition of `itostr` (a couple of keypresses in Emacs). * Read the Edoc comment for the function ("Convert integer to string"). * Jump back to where you were (one key combo). Sure, if the function was named `integer_to_string` you wouldn't have to do the above. But this was a trivial example. Many functions would take more than three words to describe what they are doing precisely, especially when your functions are granular and do exactly one thing. This can quickly lead to long lines, which I find hard to read and ugly. At the end of the day, it's all down to personal preferences and style. I like things this way, and you like them the other. It's just the way it is, and there are arguments for both approaches. For me, the benefits of terse naming outweigh its disadvantages, and the advantages of long descriptive names.

rsheridan6 18y ago

As an emacs user who is only slightly familiar with vim, I've wondered whether this may reflect a weakness of vim. With emacs + SLIME or even just dabbrev (included in emacs by default), you don't type the whole word anyway - you type an abbreviation and expand it. Does vim not have an equivalent capability? If not, that would explain why pg thinks abbreviated names are a win.

astine 18y ago
Word completion is available and it would be possible to implement something like this in vim script. But, as far as I know, vim users don't typically use this; it doesn't generally fit in with the philosophy of the editor.
- jrockway 18y ago
  So you let the philosophy of your editor get in the way of writing good code? Sounds like a plan...
  - astine 18y ago
    lol. No, you let it get in the way of extending your editor. You can write good code without abbreviation expansions. Vi hardliners would see it as unnecessary feature creep as it is rather complicated and doesn't fit in as well as other commands.
tokipin 18y ago
yes, there's abbreviation expansion. i do well enough with keyword completion though
jcl 18y ago
http://www.vim.org/htmldoc/map.html#Abbreviations http://www.vim.org/htmldoc/map.html#Abbreviations