Programming languages vary a lot, but some things are always difficult, one of these is to name variables and functions.

You probably follow some kind of code convention, like the ones for [Ruby](https://github.com/rubocop-hq/ruby-style-guide), [Python](https://www.python.org/dev/peps/pep-0008/), [Scala](https://docs.scala-lang.org/style/), or [Haskell](https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md). However, they seldom offer advice about which names to use. Here I offer you some rules I follow and a list of my preferred words (Warning: some are less than… ahem… conventional, but they work really fine).

The Rules:

- Frequent variables and functions should have short names or standard abbreviations, also, try to keep the same number of letters;
- A lot of things happens in pairs, have symmetric names for them;
- Symmetric names should have the same number of letters when possible (believe me, it makes a difference);
- Words frequently used to compose names (like input_file, output_file) should have short names (4 letters) or standard abbreviations (2 or 3 letters).

Below are the suggested names, on the left-hand side are the names that usually come to mind. On the right-hand side are alternatives, I make **bold** the ones I like most.

### Paired names

input, output => abbrev: inp, out (I prefer source/target)

in, out => **enter, leave**

from, to => **since, until** or enter, leave

**source, target** => abbrev: src, tgt

read, write => **load, save**

**produce, consume** or producer, consumer => abbrev: prd, cns

start, finish/stop => **rush, stop** / depart, cancel, arrive (this has 3 states)

enter, exit => **enter, leave**

begin, end => **begin, cease** (it’s odd until you get used to it)

open, close => **open, shut**

block, allow

up, down => abbrev: **up, dn** (side note: “dn” is “up” upside down) ;p

upper, lower

create, destroy => **create, update, delete** (3 states) / born, wake, rest, slay (those are 4 states, I like them for workers)

send, receive or sender, receiver => abbrev: snd, rec (I prefer “pull, push”, “throw, catch”, or “producer, consumer”)

**pull, push**

put, get

**throw, catch** (they are reserved in Java and probably other languages)

lock, free

soft, hard

black, white, green, amber, rouge, brown, ashes

top, bottom => **north, south**

left, right => **west, east**

width, height => **wide, tall**

original, modified

**old**, **new**

### Single Names for very short functions/methods

Those are useful for really short functions and methods, like 1 to 3 lines, or sometimes as argument names when the method is short AND generic (the classic “helper methods”.)

result => abbrev: **rslt** (I prefer it over “accumulator” or “acc” or any kind of “I’m building something and I’ll return it”)

channel => abbrev: **chnl**

file_name / filename => **path** (I really don’t like “filename” together, not sure why)

socket => **sckt**

string => **text**

x, y, z (for numbers in one-liners)

array / vector / **list** /sequence => abbrev: lst or seq (never, ever just “l”, it’s too similar to “1”), I usually don’t abbreviate it, the word is already short.

hashtable/ dictionary => abbrev: **dict** or hsh (“dict” makes a nice pair with “list”)

iterator => abbrev: **iter**

enumerator => abbrev: **enum**

Note: I usually use plural words for collections instead of “list”, “dict”. But sometimes you have a “list of I-don’t-care” and then these names makes sense.

### Loops and Iterators

**i**, **j**, **k** for indexes.

**n** when looping over numbers, not indexes.

**e** when looping over elements.

**a**, **b**, **c** when we have nested loops over elements.

**k**, **v** when iterating over keys and values of a Hashtable/Dictionary/Map.

**k**, **v**, **t**, **u** when iterating over a Dictionary of Dictionaries, but I still don’t like it.

**count**, **total** when counting and summing.

Note: if the loop has more than 2 lines, I usually avoid those short names, but they really shine in one-liners iterators/list comprehensions.

My intention is to create a Github page later and expand it. But I thought that’s better to start somewhere (even incomplete) than waiting until I “get it ready”.