6 ms·

I actually like using short variable names. Using "i" as an index variable has been widely accepted. It saves a lot of typing, the use case is clear and it is u

I actually like using short variable names. Using "i" as an index variable has been widely accepted. It saves a lot of typing, the use case is clear and it is usually tied the a block which is visually identifiable. I carry over the same principles to functions/methods. Functions are usually less than a screen which makes it rather easy to pick up the context and understand the program flow and the use of variables. I use "list" if there is there is a single list. The context usually defines what is in there. Maybe the function name, the type declarations or the fact that we are in a part of code handling lists of customers. How hard is it to guess what countCustomers(list) or incrementCustomersScore(list, n) is doing? Writing incrementCustomersScore(goodCustomerList, customerScoreDelta) is just redundant. Variable names just need to be descriptive enough to define their role within it's context. If the function is very small, the variable names can be very short. Local variables are the smallest named things in our systems, whith a very small scope, there shouldn't be an excessive naming cult around it. Give advice how to properly name projects, packages, namespaces and classes and I start listening. We are really bad at this.

Huggernaut 8y ago
I'd suggest that `count(customers)` or `incrementScore(goodCustomers, delta)` are shorter, more readable, don't embed type information in the variable name (e.g. what happens if you realise your customers are actually a set, not a list), and don't end up embedding type information in your function name (e.g. what if I want to count employees). Also, by not including semantic information in the variable, it also requires this to be conveyed everywhere else e.g. your function names. You rightly point out that hopefully there's tight context around this thing (e.g. it's only about customers) and maybe you can leave that out, but over time as code changes and grows in weird ways, this may not always hold. What do you think?
- Yokohiii 8y ago
  Embedding types in the method names is a habit of using dynamically typed languages. If the method is private it can be shorter, if it is public it should be a bit more descriptive. With statically typed languages I'd agree with your suggestion, but i'd likely would remove the type info from variables as well.
  - nailer 8y ago
    > If the method is private it can be shorter Won't other people still need to read private code?
    - Yokohiii 8y ago
      Of course, but the scope is heavily limited. This doesn't justify nonsense naming, but it can be very compact.
  - emodendroket 8y ago
    To me, if you feel compelled to start putting type information in the variable names, function names, etc., what you're showing is that you really want a type system.
  - marcosdumay 8y ago
    Having types on your API names is a good indicator that you didn't abstract your problem in separable enough concerns. It does help one turn a bad API into a bad API that will lead to slightly less bugs.
jdmichal 8y ago
`i` vs `index` is whatever. `index` is better, but it's not like I'd bash someone for using `i`. Using `list` is just bad. Your list (probably) holds a set of things that has a name. So name your list that. At the very least, name it after the type of things it's holding. Types are only declared once, but variable names are forever. Having to constantly look up the type of a variable because the programmer was too lazy to name the list of things as `things` instead of `list` is rather inconsiderate. (Of course, there are times when you would use `list`. For instance, if you're writing a list sorting function, and you actually have zero context more than "yep, this thing is a list".)
- seanmcdirmid 8y ago
  Index isn’t going to be consistent when you need a second iterator in a generic algorithm; people just don’t like the sound of jndex. Use “i” and “j” and “k”, or “idx” and “jdx” and “kdx” if you must, but please don’t use “index1” and “index2” and “index3.” As you say, list might be the best name for a variable if the use context is generic. The same with iterators and such. But you really have to think ahead to keep the names consistent, complicated names work against consistency.
  - deleted 8y ago
    [deleted]
  - jdmichal 8y ago
    Well, if you combine the two together... List<Foo> foos; for (fooIndex = 0; fooIndex < foos.length; ++fooIndex) { Foo foo = foos[fooIndex]; List<Bar> bars = foo.bars; for (barIndex = 0; barIndex < bars.length; ++barIndex) { Bar bar = bars[barIndex]; } } It would be immediately, visibly obvious if you accidently use `fooIndex` in the `bars` list. Good luck getting that with `i` and `j`. That, of course, is assuming you even need the indexes. Otherwise you get this: foreach (Foo foo in foos) { foreach (Bar bar in foo.bars) { } }
    - Jtsummers 8y ago
MrEfficiency 8y ago
My only wish is that tutorials/frameworks would name everything with Foo like iFoo, or listFoo, etc... When using these, I often dont know whats an Object that cannot be changed, and whats a variable. Sure you can play around with it, but I feel like I've lost plenty of time trying to understand other's code.
kstenerud 8y ago
> How hard is it to guess what countCustomers(list) or incrementCustomersScore(list, n) is doing? When you're as jaded as I am, very. What is list? What are its elements? Is it a list of customers? Is it a list of something that has a customer as one of its properties? I've seen far too much bullshit in my time to make any contextual assumptions about something called "list". Same goes for "n". Is that the number of customers whose scores to increment, or is it the amount to increment for each customer in the list? Or something else? What happens if it's negative? Any time I have to look inside a function (no matter how small) to see what it actually does, I find myself wondering why I must endure this extra cognitive load (and then endure again later when I read the same code but have forgotten the implementation details). And any time I find even mildly ambiguous names, I MUST assume the worst, because people just do stupid things, and therefore I must assume for my own survival that YOU have done stupid things, even if you haven't. It's very little extra effort to call it modifyCustomersScores(customers, scoreDelta) and eliminate as much guesswork as possible. Remember: Code is read FAR more often than it is written. Why wouldn't you take steps to optimize throughput on the common path? Explicit naming is a courtesy. It's developer U/X. It's telling your reader "Yes, I've been there in the trenches. I've seen the horrors. Here's a flashlight to help you on your way."
- auggierose 8y ago
  if questions like "what is list" keep you up at night, maybe switch to a statically typed programming language
  - mikert5671 8y ago
    thats not the point, the point is that you cant assume that you really know what the function is doing, too often its doing something else thats really hard to figure out without looking closely. Good code will make it so that you dont have to look closely, you can read the variable and method names.
  - bunderbunder 8y ago
    I don't think static typing is a silver bullet here. As I alluded to in another comment a moment ago, I've seen atrocities that were committed in part because someone didn't want to have to go modify a bunch of type references, or refactor the code to accommodate a new type. Local type inference ("var") can reduce the friction here, but, you've probably still got to explicitly declare types for parameters and return values, so there's always an excuse to be lazy. I'd say that full-on Hindley-Milner type inference might help, except that I suspect that the folks who do this kind of thing would find a way to create even more chaos in the kinds of languages that have one.
ben509 8y ago
> How hard is it to guess what countCustomers(list) or incrementCustomersScore(list, n) is doing? The correct comparison is: 1. what is the cumulative time wasted when people guess wrong? 2. what is the cumulative time spent writing out a meaningful name? When I'm conservative in my estimate of how good people are at guessing my intuitions, I always find that #1 seems to dwarf #2.
bluntfang 8y ago
>It saves a lot of typing Are you getting paid by least amount of characters typed?
- hinkley 8y ago
  Autocomplete means I type less than six keystrokes for most of my uses of a variable. “Fewer characters” seems to be the domain of people who place little to no value on good tools. In the worst cases they make choices that are actively hostile to anyone else using better tools. See also the Toxic 10x-er, who is really a 3x who makes everyone else 2/3rds less effective.
another-cuppa 8y ago
Short variable names like `i` are often the most appropriate. It's a thoroughly understood idiom and to use anything else just because you don't like single letters is just stupid. It's fine if you want to use a language that let's you easily avoid using indexes at all, though. But only if it's idiomatic in that language.
chrismcb 8y ago
"the context usually defines what is in there" is part of the problem. You really should need to know the context to know what a variable is. Sure "countCustomers(list)" gives you an idea of what list is (well sort of, is list a list of customers, or is it a list of people, some of whom are customers?) But "list.count" doesn't give you any info. The other issue is it makes it difficult to do global searches. And code reviews are more difficult as I may not be able to glean the context from the few lines that show up in the diff. Variable names should be succinct, as long as they need to be and no longer.
grogers 8y ago
It really depends on the team coding conventions. Our team uses 'c' for sql.Connection, 'rs' for sql.ResultSet, and 'txn' for our ORMs transactions, and we do this absolutely everywhere. The short variable names absolutely increase readability. But without the solid conventions it isn't as much of a win.

Huggernaut 8y ago

I'd suggest that `count(customers)` or `incrementScore(goodCustomers, delta)` are shorter, more readable, don't embed type information in the variable name (e.g. what happens if you realise your customers are actually a set, not a list), and don't end up embedding type information in your function name (e.g. what if I want to count employees). Also, by not including semantic information in the variable, it also requires this to be conveyed everywhere else e.g. your function names. You rightly point out that hopefully there's tight context around this thing (e.g. it's only about customers) and maybe you can leave that out, but over time as code changes and grows in weird ways, this may not always hold. What do you think?

Yokohiii 8y ago
Embedding types in the method names is a habit of using dynamically typed languages. If the method is private it can be shorter, if it is public it should be a bit more descriptive. With statically typed languages I'd agree with your suggestion, but i'd likely would remove the type info from variables as well.
- nailer 8y ago
  > If the method is private it can be shorter Won't other people still need to read private code?
  - Yokohiii 8y ago
    Of course, but the scope is heavily limited. This doesn't justify nonsense naming, but it can be very compact.
- emodendroket 8y ago
  To me, if you feel compelled to start putting type information in the variable names, function names, etc., what you're showing is that you really want a type system.
- marcosdumay 8y ago
  Having types on your API names is a good indicator that you didn't abstract your problem in separable enough concerns. It does help one turn a bad API into a bad API that will lead to slightly less bugs.

jdmichal 8y ago

`i` vs `index` is whatever. `index` is better, but it's not like I'd bash someone for using `i`. Using `list` is just bad. Your list (probably) holds a set of things that has a name. So name your list that. At the very least, name it after the type of things it's holding. Types are only declared once, but variable names are forever. Having to constantly look up the type of a variable because the programmer was too lazy to name the list of things as `things` instead of `list` is rather inconsiderate. (Of course, there are times when you would use `list`. For instance, if you're writing a list sorting function, and you actually have zero context more than "yep, this thing is a list".)

seanmcdirmid 8y ago
Index isn’t going to be consistent when you need a second iterator in a generic algorithm; people just don’t like the sound of jndex. Use “i” and “j” and “k”, or “idx” and “jdx” and “kdx” if you must, but please don’t use “index1” and “index2” and “index3.” As you say, list might be the best name for a variable if the use context is generic. The same with iterators and such. But you really have to think ahead to keep the names consistent, complicated names work against consistency.
- deleted 8y ago
  [deleted]
- jdmichal 8y ago
  Well, if you combine the two together... List<Foo> foos; for (fooIndex = 0; fooIndex < foos.length; ++fooIndex) { Foo foo = foos[fooIndex]; List<Bar> bars = foo.bars; for (barIndex = 0; barIndex < bars.length; ++barIndex) { Bar bar = bars[barIndex]; } } It would be immediately, visibly obvious if you accidently use `fooIndex` in the `bars` list. Good luck getting that with `i` and `j`. That, of course, is assuming you even need the indexes. Otherwise you get this: foreach (Foo foo in foos) { foreach (Bar bar in foo.bars) { } }
  - Jtsummers 8y ago

MrEfficiency 8y ago

My only wish is that tutorials/frameworks would name everything with Foo like iFoo, or listFoo, etc... When using these, I often dont know whats an Object that cannot be changed, and whats a variable. Sure you can play around with it, but I feel like I've lost plenty of time trying to understand other's code.

kstenerud 8y ago

> How hard is it to guess what countCustomers(list) or incrementCustomersScore(list, n) is doing? When you're as jaded as I am, very. What is list? What are its elements? Is it a list of customers? Is it a list of something that has a customer as one of its properties? I've seen far too much bullshit in my time to make any contextual assumptions about something called "list". Same goes for "n". Is that the number of customers whose scores to increment, or is it the amount to increment for each customer in the list? Or something else? What happens if it's negative? Any time I have to look inside a function (no matter how small) to see what it actually does, I find myself wondering why I must endure this extra cognitive load (and then endure again later when I read the same code but have forgotten the implementation details). And any time I find even mildly ambiguous names, I MUST assume the worst, because people just do stupid things, and therefore I must assume for my own survival that YOU have done stupid things, even if you haven't. It's very little extra effort to call it modifyCustomersScores(customers, scoreDelta) and eliminate as much guesswork as possible. Remember: Code is read FAR more often than it is written. Why wouldn't you take steps to optimize throughput on the common path? Explicit naming is a courtesy. It's developer U/X. It's telling your reader "Yes, I've been there in the trenches. I've seen the horrors. Here's a flashlight to help you on your way."

auggierose 8y ago
if questions like "what is list" keep you up at night, maybe switch to a statically typed programming language
- mikert5671 8y ago
  thats not the point, the point is that you cant assume that you really know what the function is doing, too often its doing something else thats really hard to figure out without looking closely. Good code will make it so that you dont have to look closely, you can read the variable and method names.
- bunderbunder 8y ago
  I don't think static typing is a silver bullet here. As I alluded to in another comment a moment ago, I've seen atrocities that were committed in part because someone didn't want to have to go modify a bunch of type references, or refactor the code to accommodate a new type. Local type inference ("var") can reduce the friction here, but, you've probably still got to explicitly declare types for parameters and return values, so there's always an excuse to be lazy. I'd say that full-on Hindley-Milner type inference might help, except that I suspect that the folks who do this kind of thing would find a way to create even more chaos in the kinds of languages that have one.

ben509 8y ago

> How hard is it to guess what countCustomers(list) or incrementCustomersScore(list, n) is doing? The correct comparison is: 1. what is the cumulative time wasted when people guess wrong? 2. what is the cumulative time spent writing out a meaningful name? When I'm conservative in my estimate of how good people are at guessing my intuitions, I always find that #1 seems to dwarf #2.

bluntfang 8y ago

>It saves a lot of typing Are you getting paid by least amount of characters typed?

hinkley 8y ago
Autocomplete means I type less than six keystrokes for most of my uses of a variable. “Fewer characters” seems to be the domain of people who place little to no value on good tools. In the worst cases they make choices that are actively hostile to anyone else using better tools. See also the Toxic 10x-er, who is really a 3x who makes everyone else 2/3rds less effective.

another-cuppa 8y ago

Short variable names like `i` are often the most appropriate. It's a thoroughly understood idiom and to use anything else just because you don't like single letters is just stupid. It's fine if you want to use a language that let's you easily avoid using indexes at all, though. But only if it's idiomatic in that language.

chrismcb 8y ago

"the context usually defines what is in there" is part of the problem. You really should need to know the context to know what a variable is. Sure "countCustomers(list)" gives you an idea of what list is (well sort of, is list a list of customers, or is it a list of people, some of whom are customers?) But "list.count" doesn't give you any info. The other issue is it makes it difficult to do global searches. And code reviews are more difficult as I may not be able to glean the context from the few lines that show up in the diff. Variable names should be succinct, as long as they need to be and no longer.

grogers 8y ago

It really depends on the team coding conventions. Our team uses 'c' for sql.Connection, 'rs' for sql.ResultSet, and 'txn' for our ORMs transactions, and we do this absolutely everywhere. The short variable names absolutely increase readability. But without the solid conventions it isn't as much of a win.