Variables

• This is 2.2 in the book.
  • But not all of it.
• We have seen that we need to name quantities in our algorithms.
  • This is true in programs as well.
• When we have a quantity that can change we use a variable.
  • Just once when we read it in like interest rate
  • Constantly as we compute like principal
• A variable is a location in memory that can be changed that has a type and a name.
• We will have other values that can not change in our program that we will call constants
• Constants have a location in memory with a name and a type, but they can not be changed.
• In general, when we name things in programs we call them identifiers, this is really just a fancy word for a name.
• In this section we will look at naming rules and conventions.
  • In other words, what are syntactically allowed identifiers
  • And what are permissible identifiers.
• Conventions vs syntax rules
  • We tend to think of rules as bendable, but that is not the case in programming languages.
  • The syntax rules are fixed, we can't break them.
  • The speed of light, $671\times10^6$mph, is fixed, it can't change.
• A convention is something we can break, but should not.
  • These are guidelines that make things better.
  • 70MPH, can you break it?
  • What happens if you do?
• Syntax rules for identifiers
  • Usually no white space characters
    • White space is space, tab, enter, ...
    • White space is used by most languages as a delimiter
    • A delimiter is one or more characters that provide a boundary between elements in a language.
    • Much like English, most programming languages use white space as a delimiter.
    • But we use other items as well.
  • Identifiers normally are limited in the characters from which they can be constructed.
    • No white space as above.
    • Normally no special characters, (,, ., }, ...}
      • These have a meaning in most languages and act as delimiters
    • Normally you are allowed the underscore _
    • Normally you are allowed digits, but the first position must not be a digit.
  • Finally, some worlds, called reserved words have a meaning in the language
    • for, if, while
    • Thus these words can not be used as identifiers.
  • Frequently the above rules are summarized as: identifiers must
    • Must start with a letter or the underscore
    • Must contain only letters, digits or the underscore.
    • Must not be a reserved word.
  • This is not true of all languages.
    • PHP for example uses a $ to start variables, at least some places.
  • Languages are for the most part case sensitive. (Price and price are not the same).
  • You just need to learn the identifier syntax for a given language.
  • Provide a set of valid and invalid identifiers.
• Naming conventions.
  • Programming is difficult so we generally have conventions to make our code easier to read.
  • By following naming conventions we make make it easier to understand what the program is trying to do.
  • Naming conventions are part of a style guide or a list of conventions covering the creation of programs.
  • Style guides will vary from institution to institution.
  • The enforcement of style guides will vary from institution to institution as well.
  • We have a local style guide.
  • Note this may change as integration of the department continues.
• Local naming conventions
  • First and foremost all identifiers should have a meaning.
    • This should clearly indicate what the identifiers is used for.
    • There are exceptions, but this is enforced in most places.
  • We use camelCase for variables
    • The first word is lower case.
    • Each additional word starts with upper case.
    • interestRate
  • For functions we use PascalCase
    • The first word is upper case
    • Each additional word starts with upper case.
    • CalculateMonthlyPayment
  • For constants we use UPPERCASE_UNDERSCORE
    • All letters are upper case
    • Words are separated by an underscore
    • MAXIMUM_YEARS
  • For types, we use PascalCase with a T added to the end
    • PaymentT