Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
 
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
What makes a good variable name?

BACKGROUND

All the programming languages that we teach use variables and although some things differ, they're common in that they provide a way to name a memory location for use later on. And they're common (in the languages that we teach) in that a variable name is almost always ...

 a letter
 followed by letters, digits and underscores.

In the case of PHP, variable names are preceded by a $; in the case of Perl, they're preceded by a $ a @ a % an & or a *. In the case of Tcl, they're preceded by a $ when being used but not when being set.

In all the languages that we teach, a 52 letter alphabet is used - in other words, variable names are case sensitive.

Why do we care so much about variable names to write a complete article about them? Because a good choice of variable names can turn an unreadable and un-maintainable piece of code into one that's well documented and easy to debug. Commenting your program is very important, and using descriptive variable names in many ways is just as significant.

As you set your own standards (please use my document here as a guideline) think ...

 Will my variable names by understood
 Will they provide information to the maintenance programmer
 Will they be easy to get right as more code is written
 Will they get confused with one another

CASE AND UNDERSCORING

Yes, I know you can mix upper and lower case - but do you really want to? It's so easy to use upper case for one variable, lower case for another, then to forget which you used later on.

Suggestion - keep all your "simple" variables to lower case throughout. Depending on the language you're using, you may wish to capitalise object or class names, or package names. And you may wish to write constants all in capitals.

Should you use underscores in variable names? It's up to you - if your variable name is several words joined together, you may wish (consistently) to place an underscore between words and / or to capitalise the first letter of each embedded word - sometimes known as "camel case".

In Python, you're recommended to start a private variable name with a single underscore, and an intensely private name with a double underscore. System names start AND end with double underscore.

LENGTH

It's so easy when you learn to program to use variable names like "i" and "j" but this will make your longer pieces of code almost impossible to maintain later if you continue to do so throughout. I've heard this described as "job protection" coding.

A second convention is to use abbreviations for variables - all programmers are lazy when it comes to typing, so perhaps you would prefer to write (as I once did in an example) $n/f rather that $number_pieces_fruit. But guess which of those is easier to understand later!

I'm going to recommend that you use longer variable names with full words in them rather than shortenings ... typically, I would expect to see variable names of 6 to 16 characters in length.

BUT ... that's a lot of typing!

a) There's nothing wrong with consistently using a limited number of common shortenings - "no" for "number" for example - so $no_pieces_fruit, and $info is acceptable (or perhaps preferable!) in place of $information

b) For tight code - variables used over just a few lines, such as a loop counter, you may go with variables as short as single letters - almost algebraic names such as $i and $j, or $r and $c (for row and column) or $x and $y (the two axes of a graph).

ENGLISH OR AMERICAN

center or centre? color or colour? capitalize or capitalise?

Your choice but - please - set down an organisation standard that says that "we spell the English way" or "we spell the American way".


See also Perl Standards

Please note that articles in this section of our web site were current and correct to the best of our ability when published, but by the nature of our business may go out of date quite quickly. The quoting of a price, contract term or any other information in this area of our website is NOT an offer to supply now on those terms - please check back via our main web site

Related Material

An Introduction to Standards in Perl
  [242] - ()
  [668] - ()
  [743] - ()
  [945] - ()
  [965] - ()
  [1047] - ()
  [1221] - ()
  [1345] - ()
  [1395] - ()
  [1555] - ()
  [1728] - ()
  [1853] - ()
  [1863] - ()
  [2375] - ()
  [2688] - ()
  [2875] - ()
  [3398] - ()
  [4326] - ()

Python - Applying OO design techniques and best practise
  [340] - ()
  [656] - ()
  [668] - ()
  [836] - ()
  [945] - ()
  [1181] - ()
  [2363] - ()
  [2407] - ()
  [2485] - ()
  [2523] - ()
  [2604] - ()
  [3887] - ()
  [4028] - ()
  [4118] - ()
  [4359] - ()
  [4718] - ()

Tcl/Tk - A Review of Tcl and Tk Basics
  [1092] - ()
  [1174] - ()
  [1181] - ()
  [1469] - ()
  [4208] - ()

C and C based languages - Putting it all together
  [836] - ()
  [925] - ()
  [945] - ()
  [1181] - ()
  [2646] - ()
  [2673] - ()
  [2674] - ()
  [2851] - ()
  [3067] - ()
  [3069] - ()
  [3252] - ()
  [3810] - ()
  [4326] - ()
  [4374] - ()
  [4559] - ()

Java - Putting it all together
  [2525] - ()
  [2653] - ()
  [4305] - ()

Designing PHP-Based Solutions: Best Practice
  [123] - ()
  [237] - ()
  [261] - ()
  [340] - ()
  [394] - ()
  [426] - ()
  [563] - ()
  [572] - ()
  [839] - ()
  [896] - ()
  [936] - ()
  [945] - ()
  [1047] - ()
  [1052] - ()
  [1166] - ()
  [1181] - ()
  [1182] - ()
  [1194] - ()
  [1321] - ()
  [1323] - ()
  [1381] - ()
  [1389] - ()
  [1390] - ()
  [1391] - ()
  [1482] - ()
  [1487] - ()
  [1490] - ()
  [1533] - ()
  [1623] - ()
  [1694] - ()
  [1794] - ()
  [2199] - ()
  [2221] - ()
  [2430] - ()
  [2679] - ()
  [3539] - ()
  [3813] - ()
  [3820] - ()
  [3926] - ()
  [4069] - ()
  [4118] - ()
  [4326] - ()
  [4641] - ()
  [4691] - ()

Introduction to Lua.
  [1111] - ()
  [1695] - ()
  [1699] - ()
  [1737] - ()
  [1842] - ()
  [2310] - ()
  [3724] - ()
  [4271] - ()
  [4324] - ()

resource index - Deployment
Solutions centre home page

You'll find shorter technical items at The Horse's Mouth and delegate's questions answered at the Opentalk forum.

At Well House Consultants, we provide training courses on subjects such as Ruby, Lua, Perl, Python, Linux, C, C++, Tcl/Tk, Tomcat, PHP and MySQL. We're asked (and answer) many questions, and answers to those which are of general interest are published in this area of our site.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2024: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho

PAGE: http://www.wellho.net/solutions/general- ... -name.html • PAGE BUILT: Wed Mar 28 07:47:11 2012 • BUILD SYSTEM: wizard