Naming Variables

Slides from my naming variables lecture

Transcript

1. Naming Variables
2. Stay With Me Here • Code with good variable names will have less bugs and be easier to read • If you can’t think of a good name, the variable could either be unnecessary, or you may need to think about defining the problem more
3. Examples Purpose of Variable Good Names Bad Names Number of beds numOfBeds, numBeds, numberOfBeds nob, x, nobeds Current date current_date cd, date, current, x If a user is active is_active, active?, isUserActive x, active, not_active, active_flag (eh)
4. Variable Name Should Be Descriptive • I should know what your variable does from the name. • Don’t be afraid to use longer names. • Research has shown that code with variable names averaging 10-16 characters took considerably less effort to debug. • You have (or should have) autocomplete on your text editor, you can type it out. • It leads to less typing and debugging / faster development.
5. Context Matters • There are very common patterns where we all know what the very short variable stands for. • If you’re iterating over a for loop, use ‘i’ and ‘j’. • ‘e’ for event • ‘req’ and ‘res’ for request and response • Look for any naming conventions being used on the project and follow along. Don’t be a cowboy.
6. Don’t Leave Cryptic Values In Your Code • Always name values that you’re setting. You may know what it equals now, but you will forget in the future. • You can use the variable across your code. • If you need to change the value in the future, all you have to do it change the variable value. BAD GOOD BAD GOOD
7. Temporary Variables • Beware of temporary variables. • Just because they are temporary, doesn’t mean they don’t deserve a good name. • Don’t use ‘temp’ or anything of that sort, please.
8. Booleans • Common acceptable boolean names: done, error, found, success • Your boolean name should imply true : false • Be positive. Negative names are confusing.
9. Naming Conventions • Programming is difficult enough. Don’t make it harder • Instead of worrying about naming conflicts, ‘is it no, num, or number?’, etc. You make the decision once early on what to call things. • It frees up space in your head to think about more important things.
10. Naming Conventions • They can emphasize relationships. vs
11. Naming Conventions • They can cut down on annoying debugging. • “Did I name it user or users?” • “Is it userCreate or createUser?”
12. Naming Conventions • Naming conventions make it easier for multiple people to work on the same project.
13. Guidelines for Variable Names • Be able to pronounce the variable • Standard abbreviations are alright (stdio, err, etc) • Remove articles (and, or, the, etc) • Consistently only using the first few letters of long words is OK (comp -> computer; jan -> January) • Do not use phonetic equivalents (lite, luv, etc)
14. Guidelines for Variable Names, cont. • Don’t abbreviate for a few characters • Abbreviate consistently • If you’re having a naming collision, consult a thesaurus • If the project hits a certain size, it is worth it to document naming standards.
15. Guidelines for Variable Names, cont. • Make sure your variable name accurately reflects what its naming • Avoid names with similar meanings (ex. num_users and user_num) • Avoid similar names with different meanings (celebName and celebFame in your celebrity tracker) • Avoid homophones (toUsers, twoUsers) • Avoid hard to spell words (hello word!) • Avoid ambiguous characters (I vs l) (also, pick a good font to help with this — I love Inconsolata, the font used in this slide show)
16. Guidelines for Variable Names, cont. • Don’t be cute
17. Questions?