5 ms·

Tips for naming variables

11 points by albertoG 17y ago

grunties 17y ago
Sorry Alberto, but a lot of that is context-specific advice given as general advice. 1) 'days', 'temp', 'data', etc are perfectly valid variable names in context. I'm gobsmacked that anyone can think 'temp' is a bad variable name. 3) A comment next to one instance of the variable is not sufficient - would you be happy working on code where the variable names are 'a', 'b', 'c' etc., with or without a comment in one particular place? I wouldn't. 4) I'll leave aside the eternal debate over hungarian notiation, and just point out that 'red_apples', 'yellow_apples', 'green_apples' etc would more properly be 'apples_red', 'apples_yellow', 'apples_green' etc. Least specific differentiators first. 5) Negative names are fine, in context. I don't find it any harder to parse 'disabled' than '!enabled'. I find it more distracting to have the redundant 'is' in the variable name, and it's only ever correct in some contexts. Even if I were to concede the point of polarity, "if disabled" is less of an obstacle than "if not is enabled". Then there's the issue of default - I find it much clearer in the wider scope to label the variable according to exception. For example, if a setting is enabled in 99.9% of cases, I'll use 'disabled' as the variable. If the majority is disabled, I'll use 'enabled'. This links the variable name with the intent more clearly. 7) I'm sure on occasion there's a good reason to have two identical types with different names instead of one type with a property to differentiate the two, but that ain't it. Changing the property of the item represented should map cleanly to changing the property of the variable. Your way would have you copy one type of variable to another in order to change the property. "Order->approved=true", or better still let Order do the work itself for extensibility with "Order->approve()", but not "approvedOrder = nonApprovedOrder; nonApprovedOrder = null;". Gah!
babo 17y ago
Stopped reading here: "Good example: daysFromDateRangeStartToEnd".
- mrduncan 17y ago
  Seems like the author didn't take his own advice - "2.- The variable name has to be as short as possible."
- albertoG 17y ago
  Hi babo, you are absolutely right with your observation, that variable name its just a bad example, I have just edited the post and I have changed its name to daysDateRange. Thanks for your feedback
  - pwim 17y ago
    Neither your original daysFromDateRangeStartToEnd nor daysDateRange seem to capture what it is supposed to represent. Perhaps if it was seen in context, it would be understandable, but by itself I do not think it is a good example.
mojuba 17y ago
void swap(int* x, int* y) { int t = *x; *x = *y; *y = t; } Small blocks with very obvious code are perfectly Ok to have short variable names in. All other rules in this post can be criticized as easily. Hence, rule #8: forget about the previous rules, just be a smart coder.
- sethg 17y ago
  Indeed, I think one very useful rule for naming variables is "the length of the name should be proportional to the scope". If you're iterating through a list of objects representing unfilled orders, it's OK to do this: for uo in unfilledOrdersIterator(): oid = uo.id status = uo.status email = uo.customer.email sendEmail(email, "Your order %s is in status %s" % (oid, status)) But if there's a 200-line method that does all sorts of other things with a single unfilled order, then calling the order "uo" is probably a bad idea.
  - pp 17y ago
    Shouldn't there NOT be 200-line methods in the first place?
    - nuclear_eclipse 17y ago
      There are some cases where 200-line methods are perfectly acceptable, when breaking the logic into smaller functions only complicates the understanding and development of the algorithm. Not everything can be broken into multiple elegant 10-line functions without obfuscating the purpose or control flow.
      - mojuba 17y ago
        Formally speaking, every line and every block (if, while...) can be moved to a separate function. Provided that functions are given fairly descriptive names, it is always possible to go as far as you wish in splitting your functions into smaller ones. I don't see any problem with that except reading/understanding, of course, which depends on your "target audience" so to say. If you have a good sense of code aesthetics, you can make your code look like pseudo-code, which every decent coder is supposed to understand. So your quicksort may look almost like: function quicksort(array) var list less, greater if length(array) ≤ 1 return array select and remove a pivot value pivot from array for each x in array if x ≤ pivot then append x to less else append x to greater return concatenate(quicksort(less), pivot, quicksort(greater)) or it may be a 50-liner with no sub-routines. It's a matter of choice, really.
Deestan 17y ago
> Example. If your customer just considers “order” an “order” that has been approved, don’t call “order” to a non approved one in your code, call it “nonApprovedOrder”. Doesn't this violate his rule #5?
- albertoG 17y ago
  Hi Deestann, good catch, I should have stressed that these are guidelines not rules, what I meant is if possible use positive logic, but it fits better the negative, use the negative one. Thanks for the comment
ashleyw 17y ago
Ideally should be using short methods, so what's wrong with using generic names?
Daniel_Newby 17y ago
"Don´t use negative logic for your variable names." Obviously written by a software weenie who lives far, far away from the actual hardware. ;-) (Digital logic often uses active-low signals for good electrical reasons. And some purely historic reasons: do memory chips actually need to power up in the activated state?)
- wlievens 17y ago
  What what what?
  - Daniel_Newby 17y ago
    Many circuits work with Boolean values that are true in the 0 state, and false in the 1 state: negative logic. That had better be reflected in the variable names.

11 points by albertoG 17y ago

Sorry Alberto, but a lot of that is context-specific advice given as general advice. 1) 'days', 'temp', 'data', etc are perfectly valid variable names in context. I'm gobsmacked that anyone can think 'temp' is a bad variable name. 3) A comment next to one instance of the variable is not sufficient - would you be happy working on code where the variable names are 'a', 'b', 'c' etc., with or without a comment in one particular place? I wouldn't. 4) I'll leave aside the eternal debate over hungarian notiation, and just point out that 'red_apples', 'yellow_apples', 'green_apples' etc would more properly be 'apples_red', 'apples_yellow', 'apples_green' etc. Least specific differentiators first. 5) Negative names are fine, in context. I don't find it any harder to parse 'disabled' than '!enabled'. I find it more distracting to have the redundant 'is' in the variable name, and it's only ever correct in some contexts. Even if I were to concede the point of polarity, "if disabled" is less of an obstacle than "if not is enabled". Then there's the issue of default - I find it much clearer in the wider scope to label the variable according to exception. For example, if a setting is enabled in 99.9% of cases, I'll use 'disabled' as the variable. If the majority is disabled, I'll use 'enabled'. This links the variable name with the intent more clearly. 7) I'm sure on occasion there's a good reason to have two identical types with different names instead of one type with a property to differentiate the two, but that ain't it. Changing the property of the item represented should map cleanly to changing the property of the variable. Your way would have you copy one type of variable to another in order to change the property. "Order->approved=true", or better still let Order do the work itself for extensibility with "Order->approve()", but not "approvedOrder = nonApprovedOrder; nonApprovedOrder = null;". Gah!

babo 17y ago

Stopped reading here: "Good example: daysFromDateRangeStartToEnd".

mrduncan 17y ago
Seems like the author didn't take his own advice - "2.- The variable name has to be as short as possible."
albertoG 17y ago
Hi babo, you are absolutely right with your observation, that variable name its just a bad example, I have just edited the post and I have changed its name to daysDateRange. Thanks for your feedback
- pwim 17y ago
  Neither your original daysFromDateRangeStartToEnd nor daysDateRange seem to capture what it is supposed to represent. Perhaps if it was seen in context, it would be understandable, but by itself I do not think it is a good example.

mojuba 17y ago

void swap(int* x, int* y) { int t = *x; *x = *y; *y = t; } Small blocks with very obvious code are perfectly Ok to have short variable names in. All other rules in this post can be criticized as easily. Hence, rule #8: forget about the previous rules, just be a smart coder.

sethg 17y ago
Indeed, I think one very useful rule for naming variables is "the length of the name should be proportional to the scope". If you're iterating through a list of objects representing unfilled orders, it's OK to do this: for uo in unfilledOrdersIterator(): oid = uo.id status = uo.status email = uo.customer.email sendEmail(email, "Your order %s is in status %s" % (oid, status)) But if there's a 200-line method that does all sorts of other things with a single unfilled order, then calling the order "uo" is probably a bad idea.
- pp 17y ago
  Shouldn't there NOT be 200-line methods in the first place?
  - nuclear_eclipse 17y ago
    There are some cases where 200-line methods are perfectly acceptable, when breaking the logic into smaller functions only complicates the understanding and development of the algorithm. Not everything can be broken into multiple elegant 10-line functions without obfuscating the purpose or control flow.
    - mojuba 17y ago
      Formally speaking, every line and every block (if, while...) can be moved to a separate function. Provided that functions are given fairly descriptive names, it is always possible to go as far as you wish in splitting your functions into smaller ones. I don't see any problem with that except reading/understanding, of course, which depends on your "target audience" so to say. If you have a good sense of code aesthetics, you can make your code look like pseudo-code, which every decent coder is supposed to understand. So your quicksort may look almost like: function quicksort(array) var list less, greater if length(array) ≤ 1 return array select and remove a pivot value pivot from array for each x in array if x ≤ pivot then append x to less else append x to greater return concatenate(quicksort(less), pivot, quicksort(greater)) or it may be a 50-liner with no sub-routines. It's a matter of choice, really.

Deestan 17y ago

> Example. If your customer just considers “order” an “order” that has been approved, don’t call “order” to a non approved one in your code, call it “nonApprovedOrder”. Doesn't this violate his rule #5?

albertoG 17y ago
Hi Deestann, good catch, I should have stressed that these are guidelines not rules, what I meant is if possible use positive logic, but it fits better the negative, use the negative one. Thanks for the comment

ashleyw 17y ago

Ideally should be using short methods, so what's wrong with using generic names?

Daniel_Newby 17y ago

"Don´t use negative logic for your variable names." Obviously written by a software weenie who lives far, far away from the actual hardware. ;-) (Digital logic often uses active-low signals for good electrical reasons. And some purely historic reasons: do memory chips actually need to power up in the activated state?)

wlievens 17y ago
What what what?
- Daniel_Newby 17y ago
  Many circuits work with Boolean values that are true in the 0 state, and false in the 1 state: negative logic. That had better be reflected in the variable names.