# How to organise the variable names in R without messing up?

When I work in R, every time I create a new variable I try to name it simple so that it iss easy to type like x1, x2, ... or a1, a2, ... Sometimes I use temporary variables with names temp, and again I continue making variables temp1, temp2, .... As a result finally I mess up everything to a point impossible to understand the data if looked at after some days. Is there any easy way or rule to follow in creating new variables and organizing them?

-
You can have a look to coding convention : Google's R Style Guide or Bioconductor - Coding Style. This does not fully answer your question but it's a good start I think. –  Julien D. Jun 12 '14 at 5:35

Use simple phrases

Rather than relying on very generic variable names like x1, x2, y1, y2, develop a very simple variable name system:

Common variables: Some variables are so ubiquitous that it's just easier to name them as is: male, edu, income or inc, age, etc. As time goes on the naming of this variable will be nearly instinctive.

Keep it short: Keep the name within 6-8 characters. I don't usually use upper case because I tend to save upper case characters for function names. But it's also acceptable to use system such as satFat (saturated fat), skMilk (skim milk) to chain up two words with one capital letter without hurting readability.

Slash vowels: Most of the English words can still be quite discernible without vowels. For instance, sector vs. sctr, district vs. dstrct, group1 vs grp1, quartile vs. qrtl. Again, it's a matter of habit and soon you will be able to name and recognize them quickly.

Keep syntax

Whatever you do, save the syntax. And keep periodic back up after each major revision so that you have an archive of your analysis flow. (aka, don't keep overwriting your one single file, save a historic cascade of copies.)

With a good syntax keeping habit, even moderately messy variable naming will not be a major problem as users can always trace back how each variable comes about.

Sign and date your syntax and demand other people to do so. Start the syntax by information like:

# Childhood obesity analysis (project name)
# by Penguin Knight
# e-Mail: xxxxxxx@gmail.com
# Phone:  ext: 10101
# Date: Jun-12-2014
# Description of the analysis: blah blah blah.
# Version: 1.00
# Revision date and history:


That way, even later someone looking at your syntax may be lost, they can still contact you to discuss and generate some clues.

Use comments as much as commands. Syntax like:

lm(y ~ x1)


can be cryptic, but this will not confuse you as badly:

# y:  body fat percent
# x1: weekly fastfood meals frequency
lm(y ~ x1)


I may go so far to suggest that for each action, there should be at least one line of comment. Even it's something you have done million times in that week, once you have put down the project for a couple of weeks, it would be very hard to figure out what was going on.

Maintain a code book

Use comment function to maintain a code book: You can also dedicate a section to put all the variable names and their description at the same place. I often use code such as @codebook to start the code book section, and then whenever I need to look at the code book I just use Ctrl-F to search for the phrase @codebook and I'll be right there.

Keep a separate file: For large group projects that involve more collaborators, I would suggest using a separate file such as an Excel file (or even another R data file) to maintain a code book.

The data collection tools also make great code books: If you work on a questionnaire, you can also use a red pen to write down the variable name next to each item. I also use text boxes for that purpose if I need to work on an electronic version.

Use suffixes and prefixes

Develop a suffix and prefix system of your own to quickly identify the variables. For instance, I always put sv in front of all those scratch variables that I don't care to keep. In some software like Stata, this prefix can allow users to quickly clean them out by just typing:

drop sv*


Attach units: Another good use of suffix is to display unit. For instance, ageyr and agemo as age in years and months. inc1000 as income in 1000s. gdp2012, gdp2013 as GDP data of years 2012 and 2013, etc.

Attach label: You may also use prefix to determine strata: e.g. use m and f in conjunction to variable that are for males and females: medu, fedu.

I tend to avoid "." and "_": Most of the time these two characters cause problems when exporting data for another software package.

Develop a style, and stick to it

The most important point is to stick to your code style no matter how big or trivial the project is. Maintaining code legibility is not just a way to keep your stress and confusion in check, it's also a professional courtesy and ethics.

-

Got too long for a comment, so I guess it's an answer now.

Use long, descriptive names for anything you need to keep around for more than a couple of minutes.

The long names might be a nuisance to type, but if you're working by running scripts, writing functions and so on, the actual typing is not that much anyway.

But even a lot of typing is far easier than trying to figure out what you did with variables you can't remember.

Imagine you need to figure out what you did in 6 months or a year - or imagine some other poor person in the same position. Write your code for poor future-you. Help future-you out by making everything as obvious as possible. Imagine future-you can't remember anything about what you're doing.

It's nearly always better to have scripts that generate your calculations, and document them as well as making them readable. To that end, also delete variables you don't need, it will help keep you disciplined about making everything generatable again.

Keep related variables in data frames or lists (and keep related matrices, data frames and so in inside lists when there are more than a couple of them), and name all your data frame columns and your list components with names that explain what they are.

-
Long names are not much of a problem if you use a decent IDE, which offers tab-completion, so +1 for descriptive names. But don't make the names too long, because that can make code difficult to read. –  Roland Jun 12 '14 at 13:41
@Roland there's certainly a problem if you go too far the other way (names should preferably be short enough that reasonably simple expressions still fit on a single line), but from the way the OP writes, I don't think that's the main danger. Use of things like with and within and functions in R can help reduce the overhead of having (say) 15 character column names inside a 15 character name for a data-frame. –  Glen_b Jun 12 '14 at 20:48

Just don't use obscure names like x1. It's important, both from a computing as well as an analyzing perspective, to take a minute to look at your variable and understand what it represents. It's name should naturally be what it represents. For example, if it's a vector of ages, why not name it age? If it's a large name, you can reduce it, but try to make it so --- as Glen put it --- future-you will understand what present-you was talking about.

If you want to create backup objects, my tip is to prepend it's name with a dot (.) so it is invisible to ls() (but not to ls(all.names = TRUE)). I use this often, but sometimes I want to be able to see the backup object at all times, so I append .bak to the name.

-