Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Variables

318 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Variables

  1. 1. Variables 1
  2. 2.  General Issues in Using Variables:  Guidelines for Initializing Variables.  Scope  Persistence.  Binding time.  Using each variable for exactly one purpose.  Variables declaration. 2
  3. 3.  The Power of Variable Names:  Considerations in choosing good names.  The power of naming conventions.  Informal naming conventions.  Standardized prefixes.  Creating short names that are Readable.  Kinds of names to avoid. 3
  4. 4. General Issues in Using Variables 4
  5. 5.  Improper initialization problem.  Reasons:  The variable has never been assigned a value.  Part of the variable has been assigned a value and part has not.  The value in the variable is outdated . 5
  6. 6.  Solutions:  Initialize each variable as it's declared.  Use const when possible.  Pay attention to counters and accumulators.  Initialize a class's member data in its constructor.  Check the need for re-initialization.  Take advantage of your compiler's warning messages  Check input parameters for validity .  Use a memory-access checker to check for bad pointers.  Initialize working memory at the beginning of your program. 6
  7. 7.  Scope is variable visibility.  We can measure scope by:  Live time.  Span. 7
  8. 8.  live time is total number of statements over which a variable is live . 1 int recordIndex = 0; 2 bool done = false; ... ... 26 while ( recordIndex < 10) {...} 64 while ( !done ) { ... } 1 int recordIndex = 0; 2 while ( recordIndex < 10) {...} ... ... 63 bool done = false; 64 while ( !done ) { ... } 8
  9. 9.  Why we try to restrict live time?  You can concentrate on a smaller section of code.  Code more readable.  reduces the chance of initialization errors .  Easy to modify. 9
  10. 10.  Span is how you keep variable references close. 1. 2. 3. 4. 1. 2. 3. 4. a = 0; a++; a+= 10; a = 3; Life time = (4-1 +1) = 4 Average span = (0+0+0)/3 = 0; a = 0; b= 1; c = 0; a = b + c; Life time = (4-1 +1) = 4 Average span = 2/1 = 2; 10
  11. 11. 11
  12. 12.  Initialize variables used in a loop immediately     before the loop . Don't assign a value to a variable until just before the value is used. Break groups of related statements into separate routines . Begin with most restricted visibility, and expand the scope if necessary . Keep both span and live time as short as you can. 12
  13. 13.  Persistence is life span of a piece of data .  Problem: When you assume variable is persist but it's not .  Solution:  Set variables to "unreasonable values" when they doesn’t persist.  Use assertions to check critical variables.  Declare and Initialize all data right before it's used. 13
  14. 14.  The time at which the variable and its value are bound. titleBar.color = 0xFF; titleBar.color = TITLE_BAR_COLOR; titleBar.color = ReadTitleBarColor( ) Code-Writing Time Compile Time Run Time The later you bind, the more flexibility you get and the higher complexity you need . 14
  15. 15.  Use each variable for one purpose only. // Compute roots of a quadratic equation temp = Sqrt( b*b - 4*a*c ); root[0] = ( -b + temp ) / ( 2 * a ); root[1] = ( -b - temp ) / ( 2 * a ); ... // swap the roots temp = root[0]; root[0] = root[1]; root[1] = temp ; Creating unique variables for each purpose makes code more readable. 15
  16. 16.  Avoid hybrid coupling. Double use is clear to you but it won't be to someone else.  Make sure all declared variables are used. 16
  17. 17. Initializing Variables  Does each routine check input parameters for validity?  Does the code declare variables close to where they're first used?  Does the code initialize variables as they're declared, if possible?  Are counters and accumulators initialized properly and, if necessary, reinitialized each time they are used?  Does the code compile with no warnings from the compiler? 17
  18. 18. Other General Issues in Using Data  Do all variables have the smallest lift time possible?  Are references to variables as close together as possible?  Are all the declared variables being used?  Are all variables bound with balance between the flexibility and the complexity associated?  Does each variable have only one purpose?  Is each variable's meaning explicit, with no hidden meanings? 18
  19. 19. The Power of Variable Names 19
  20. 20. x = x - xx; xxx = fido + SalesTax( fido ); x = x + LateFee( x1, x ) + xxx; x = x + Interest( x1, x ); balance = balance - lastPayment; monthlyTotal = newPurchases + SalesTax( newPurchases ); balance = balance + LateFee( customerID, balance ) + monthlyTotal; balance = balance + Interest( customerID, balance ); A good variable name is readable, memorable, and appropriate . 20
  21. 21.  The Most Important Naming Consideration:  Good name is to state what the variable represents.  Optimum Name Length. Don’t be maximumNumberOfPointsInModernOlympics or np But be teamPointsMax 21
  22. 22.  Are short names always bad?  Common Opposites in Variable Names.  maxPoints OR pointsMax OR both ?  Avoid the confusion between maxPoints and pointsMax .  The most significant part of the variable name is at the front. 22
  23. 23.  loop variables:  Don’t use i, j, and k if: 1. variable is to be used outside the loop. 2. the loop is longer than a few lines. 3. you write nested loops. Try to avoid altogether . Code is so often changed, expanded, and copied into other programs. 23
  24. 24.  Naming Status Variables:  A flag should never have flag in its name .  Use constants and enumerator for its value. reportType == ReportType_Annual is more meaningful than reportflag == 0x80 .  Naming Temporary Variables:  Use descriptive variable name instead of temp. 24
  25. 25.  Naming Boolean Variables:  Give Boolean variables names that imply true or false. (done , error ,found ,success)  Don’t use negative boolean variable names . (if not notFound)  Naming Enumerated Types:  Using group prefix if your language doesn’t support. Enum Color {Color_Red , Color_Green }  enum type itself can include prefix (enColor). 25
  26. 26.  When Should Have a Naming Convention  When multiple programmers are working on a project  When you plan t turn a program over to another programmer  When programs are reviewed by other programmers  When program is so large that you think about it in pieces  When the program will be long-lived enough 26
  27. 27.  Why we Have Conventions?  One global decision rather than many local ones .  They help you transfer knowledge across projects.  They reduce name proliferation.  They compensate for language weaknesses.  You work with a consistent code. 27
  28. 28.  Differentiate between classes and objects via:  Initial Capitalization Widget widget.  All Caps WIDGET widget.  "t_" Prefix for Types t_Widget Widget.  More Specific Names for the Variables Widget employeeWidget .  Identify member variables. with an m_ prefix. 28
  29. 29.  Identify named constants . Via uppercase letters.  Identify elements of enumerated types.  Use all caps or an e_ or E_ prefix for the name of the type.  Use a prefix based on the specific type like Color_Red.  Format names to enhance readability. CIRCLEPOINTTOTAL is less readable than circlePointTotal or circle_point_total. 29
  30. 30.  Guidelines for Language-Specific Conventions:  i and j are integer indexes.  p is a pointer.  Constants and macros are in ALL_CAPS.  Class and other types are in MixedUpperAndLowerCase().  Variable and function names as variableOrRoutineName.  The underscore is not used as a separator within names, except for names in all caps and certain kinds of prefixes 30
  31. 31.  As avgSize, maxNum, firsIndex.  Advantages of Standardized Prefixes:  Naming conventions advantage +  You have fewer names to remember.  Make names more compact. 31
  32. 32.  General Abbreviation Guidelines:  Remove all nonleading vowels (screen becomes scrn).  Remove and, or, the, and so on.  Use the first/first few letters of the name.  Keep the first and last letters of each word.  Remove useless suffixes—ing, ed, and so on.  Keep the most noticeable sound in each syllable. Be sure not to change the meaning of the variable. 32
  33. 33. Comments on Abbreviations:  Don't abbreviate by removing one character from a word.  Abbreviate consistently. Num everywhere or No .  Create names that you can pronounce Use xPos rather than xPstn.  Avoid combinations that result in misreading . Use bEnd/b_Endrather than bend  Use a thesaurus to resolve naming collisions.  Document all abbreviations in a document.  A reader of the code might not understand the abbreviation.  Other programmers might use multiple abbreviations to refer to the same word. 33
  34. 34.  Avoid misleading names or abbreviations. As FALSE as abb for "Fig and Almond Season.“.  Avoid names with similar meanings. As fileNumber and fileIndex .  Avoid variables with different meanings but similar names. As clientRecs and clientReps .  Avoid names that sound similar. As wrap and rap.  Avoid numerals in names. As file1,file2 34
  35. 35.  Avoid words that are commonly misspelled in English. As occassionally, acummulate, and acsend.  Don't differentiate variable names solely by capitalization. As count and Count.  Avoid multiple natural languages As "color" or "colour”. 35
  36. 36. ? programmers over the lifetime of a system spend more time reading code than writing code. 36
  37. 37.  Steve McConnell, June 2004, Code Complete: A Practical Handbook of Software Construction, 2nd edn. 37
  38. 38. 38

×