Slide 1

Slide 1 text

Naming Variables

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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)

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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.

Slide 8

Slide 8 text

Booleans • Common acceptable boolean names: done, error, found, success • Your boolean name should imply true : false • Be positive. Negative names are confusing.

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

Naming Conventions • They can emphasize relationships. vs

Slide 11

Slide 11 text

Naming Conventions • They can cut down on annoying debugging. • “Did I name it user or users?” • “Is it userCreate or createUser?”

Slide 12

Slide 12 text

Naming Conventions • Naming conventions make it easier for multiple people to work on the same project.

Slide 13

Slide 13 text

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)

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

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)

Slide 16

Slide 16 text

Guidelines for Variable Names, cont. • Don’t be cute

Slide 17

Slide 17 text

Questions?