Programming and Programming Methods

1
Programming and Programming Methods
2
Developing Software (the traditional approach)

• Developers go through a number of phases and
  complete each before moving to the next one

3
Overview

• Choice of programming language
• Good programming practice
• Coding standards

4
Implementation

• Real-life products are generally too large to be
  implemented by a single programmer
• This chapter therefore deals with
  programming-in-the-many

5
Programming Languages

• A program is written by a developer in a special
  computer language.
• E.g. C, C, Pascal, BASIC, Java.
• It is then translated by a special program
  (compiler) into machine code (In case of Java
  Java byte code).
• Machine code (and Java byte code) consists of
  binary numbers (0s and 1s) that computers
  understand.

6
A Brief History of Programming Languages

• Assembly language
• First and most basic language.
• Each of the separate instructions that a computer
  understand is represented by a word that is a bit
  like English. E.g. MOV for move, SUB for
  subtract.
• A special piece of software (called assembler) is
  then used to convert our program into machine
  code.
• Low level language.

7
A Brief HistoryContinued

• Most programs require sophisticated instructions.
  Very difficult to write in assembly.
• High level languages (also known as 3GLs) were
  created.
• C, COBOL, PASCAL, BASIC
• The set of programming instructions is called the
  program code, or source code.
• Translation into the machine code is known as
  compilation (using a Compiler).

8
Object Oriented Programming Languages

• The most recent development in the history of
  programming languages
• E.g. Java, C
• Java programs are compiled and run differently to
  other languages.
• Lets see this difference!

9
Fourth Generation Languages

• First generation languages
• Machine languages (binary machine code
  instructions)
• Second generation languages
• Assemblers (symbolic notation such as mov 4,
  next)
• Third generation languages
• High-level languages (COBOL, FORTRAN, C, Java)
• One 3GL statement is equivalent to 510 assembler
  statements
• Fourth generation languages (4GLs)
• Non-procedural language (easier to code )
  Natural?
• Each 4GL statement was intended to be equivalent
  to 30 or even 50 assembler statements

10
Fourth Generation Languages

• It was hoped that 4GLs would
• One 4GL statement is equivalent to many assembler
  statements easier to understand, shorter .
• Speed up application-building
• Result in applications that are easy to build and
  quick to change
• Reducing maintenance costs
• Simplify debugging
• Make languages user friendly
• Leading to end-user programming
• Achievable if 4GL is a user friendly, very
  high-level language

11
Productivity Increases with a 4GL?

• 4GL productivity increases of 10 to 1 over COBOL
  have been reported

12
Fourth Generation Languages (contd)

• Market share
• No one 4GL dominates the software market
• There are literally hundreds of 4GLs
• Dozens with sizable user groups
• Oracle, DB2, and PowerBuilder are popular
• Reason
• No one 4GL has all the necessary features
• Conclusion
• Care has to be taken in selecting appropriate 4GL

13

• Good Programming Practice

14
Good Programming Practice

• Use of consistent and meaningful variable names
• Meaningful to future maintenance programmers
• Consistent to aid future maintenance programmers

15
Use of Consistent and Meaningful Variable Names

• A code artifact includes the variable names
• freqAverage, frequencyMaximum,
• minFr, frqncyTotl
• What is the problem ?
• A maintenance programmer has to know if freq,
  frequency, fr, frqncy all refer to the same thing
• What do instead
• If so, use the identical word, preferably
  frequency, perhaps freq or frqncy,but not fr
• If not, use a different word (e.g., rate) for a
  different quantity

16
Consistent and Meaningful Variable Names

• We can use frequencyAverage, frequencyMyaximum,
  frequencyMinimum, frequencyTotal
• We can also use averageFrequency,
  maximumFrequency, minimumFrequency,
  totalFrequency
• But all four names must come from the same set

17
The Issue of Self-Documenting Code

• Self-documenting code is exceedingly rare
• The key issue Can the code artifact be
  understood easily and unambiguously by
• The SQA team
• Maintenance programmers
• All others who have to read the code

18
Self-Documenting Code Example

• Example
• Code artifact contains the variable
  xCoordinateOfPositionOfRobotArm
• This is abbreviated to xCoord
• Is that fine to abbreviate?
• This is fine, because the entire module deals
  with the movement of the robot arm
• What about for other users of the code ?
• But does the maintenance programmer know this?

19
Prologue Comments

• Minimal prologue comments for a code artifact

20
Comments

• It is useful to have comments in your code
• It helps remind us what we were doing.
• It helps other people to understand our code.
• We want the compiler to ignore these comments!
• Two ways of doing this
• Short comments we place two slashes (//) at the
  beginning of the line-everything up to the end of
  the line is ignored.
• Longer comments (more than one line comments)
  /we ecnlose the comment between two special
  symbols/,
• the opening (/) and the closing (/).

21
Other Comments

• Suggestion
• Comments are essential whenever the code is
  written in a non-obvious way (?)
• or when makes use of some subtle aspect of the
  language (?)
• Often a bad sign !
• Instead
• Recode in a clearer way
• We must never promote/excuse poor programming
• However, comments can assist future maintenance
  programmers

22
Code with Comments
// this is a short comment, so we use the first
method class Hello5 public static void
main(String args) System.out.println("He
llo world") EasyIn.pause("Press ltEntergt to
quit") / this is the second method of
including comments it is more convenient to
use this method here, because the comment is
longer and goes over more than one line /
23
Code Layout for Increased Readability

• Use indentation
• Better, use a pretty-printer
• Use plenty of blank lines
• To break up big blocks of code

24
Nested if Statements

• Example
• A map consists of two squares. Write code to
  determine whether a point on the Earths surface
  lies in map square 1 or map square 2, or is not
  on the map

25
Nested if Statements

• Solution 1. Badly formatted

26
Nested if Statements

• Solution 2. Well-formatted, badly constructed

27
Nested if Statements

• Solution 3. Acceptably nested

28
Nested if Statements

• A combination of if-if and if-else-if statements
  is usually difficult to read
• Simplify The if-if combination
• if ltcondition1gt
• if ltcondition2gt
• is frequently equivalent to the single condition
• if ltcondition1gt ltcondition2gt

29
Nested if Statements

• Rule of thumb
• if statements nested to a depth of greater than
  three should be avoided as poor programming
  practice

30
Desirable coding style
C ??? ? 2 ?? ?? ??? ?? Void FillPowersArray(int
base, int power) powers base powers1
basebase powers2 basebasebase powers3
basebasebase base powers4
basebasebase base base powers5
basebasebase base base base powers6
basebasebase base base base
base powers7 basebasebase base base
base base base base (a) Not
Desirable void FillPowersArray(int base, int
power) powers base for( i2 ilt 8
i) pwers 1 powers 1-1base (b)
Desirable
31
Desirable coding style
Style 1 (??) ???? ????. ??? ????? ??? ?? ?????.
???? ????? ??? ??. 16???? ??? ?? ????? ?? ????
???? ??? ???? ??????. Int IntegerFromHex(char
HexDigit) if (HexDigit lt58) return
(HexDigit - 48) else return (HexDigit -
56) / ?) 0-9?? ASCII ???? 48?? 57?? ????
?? ?? ASCII??? 48? ?? ??. A - F gt 65 - 70 /
32
Desirable coding style
int IntegerFromHex(char HexDigit) Switch(char
HexDigit) case 0 IntegerFromHex 0
break case 1 IntegerFromHex 1 break
case 2 IntegerFromHex 2 break case
3 IntegerFromHex 3 break case 4
IntegerFromHex 4 break case 5
IntegerFromHex 5 break case 6
IntegerFromHex 6 break case 7
IntegerFromHex 7 break case 8
IntegerFromHex 8 break case 9
IntegerFromHex 9 break case A
IntegerFromHex 10 break case B
IntegerFromHex 11 break case C
IntegerFromHex 12 break case D
IntegerFromHex 13 break case E
IntegerFromHex 14 break case F
IntegerFromHex 15 break ? ????? 16???
???? ??? ??? ASCII?? ????? ?? ??? ??? ? ??. ?
????? ???? ???? ????.
33
Use structured coding

• ??? ?? ??
• ??? ??? ??, ??, ???? ??????? ?? ??? ??? ??? ?
  ??. ???? GOTO?? ??? ??? ??? ?? ??? ????. ??? ????
  GOTO?? ??? ??? ???? ?? ???? ??.
• DO 50 I1, COUNT
• .
• .
• .
• IF (ERROR1) GO TO 60
• .
• .
• .
• IF (ERROR2) GO TO 70
• .
• .
• .
• 50 CONTINUE
• 60 Code for Error1 handling

34
Use structured coding (in table search)
I1 While I lt TableSize and
Table(I) ltgt Target do II1 If
IgtTableSize then code for target not
found else code for target found (a)
structured coding for I1 to TableSize do
if Table(I) Target then goto
Found NotFound code for Target then goto
Found Found code for Target found (b)
GO TO statement (a)? ? ?? ??? ???? ?????? (b)? ?
????? ?? ?? ??????. ??? ?? ??? ?????? ??? ???
???? ???? ????? ???? ?? ???. ??? ????? ??? ???
?? ??? ?? ??? ??? ?? ??? ???? ????? ???? ???.

35
Desirable coding style
????? ?? ??? ??? ??? ??? ??? ???. ?? ????
??? ???? - ???? ?? ???? ???? ?? ???. -
????? ????? ??? ??? ??? ??? ????. Style 1
Write clearly. C ??? ? 1)
36
Desirable coding style
Style 2 Write directly what you intend to. if
( x lt y ) if ( x lt z ) small x
if ( x gt z ) small x if ( x lt y )
if ( y lt z ) small y if ( y gt z )
small z x, y, z ??? ? ?? ?? ?? ?? ??
small??? ??? ?????? ???? ??? ??? ?? ?? ? ??. ???
x, y, z?? ?? ?? ?? ?? small?? ??? ?? ??
???. Small x if ( y lt small ) small y
if ( z lt small ) small z ?? ??????? ??
??? ?? ???? ?? ???? ?? ?? ??.
Not desirable !!
Desirable !!
37
Desirable coding style
If . . . Else ??????? ?? ??? ?? ?? ?? ???? ??. ?
else ??? if??? ??? ?? ???. if
(in_user_code) in_user_code FALSE
r2 r reset_phariap()
send_sig_segv() else revert() if not
(in_user_code) revert()
else in_user_code FALSE r2
r reset_pharlap() send_sig_segv()

Not desirable !!
Desirable !!
38
Desirable coding style
Style 3 Avoid temporary use of variables. ????
????? ?????? ???? ???? ??? ? ?? ?? ???? ???? ???
??. ?) t1 x1-(x2x2) t2 7 - x2
y t1t1t2t2 / ??? ?? ???? ????? ????
?? ?? ?? ?? ?? / y 2(x1-2x2) 2
(7-x2) (??? ??? t1,t2?? ??? ??? ?? ??? ?????
??? ?? ?????.) Note ?????? ?? ??? ?? ????
????? ??? ???? ??? ???? ?? ??? ?? ?? ??? ???
????.
Not desirable !!
Desirable !!
39
Desirable coding style
Style 4 Use variable name not confusing. -
??? ??? ? ?? ?? - ??? ???? ?? ????? ??
? ??? ?? ???? ???? ?? ??? ???? ??.
?, PositionX ? PositionY? XPos, YPos? ?? ? ????
?? ??? ??? ?? ??. - ??? ??? ???. ??? ???
???? ??. ?) XPstn ??? XPos
40
Desirable coding style
- Use similar or identical length of variable
for consistency Not desirable) n
K nn KK nnn
KKK Desirable) nunit K
nsqur KK ncube KKK
41
Desirable coding style
Style 5 Use Consistent Rule in Variable
naming (Not desirable program) char
buffer500, mssge80 / ?? ??? ??? ??
/ void read_instance(void),
Savecurrent(void)
/ ??? ??? ??
/ void get_line(void), write_line(void)
int index1, index2
/ ???? ??
??? ?? ?? / int dirctry, Vsble

/ ?? ???? ?? /
42
Desirable coding style
Style 7 Use ifelse only for selection purpose
from exclusive choices (Not Desirable if
(swct1 1) goto Conti else
dvict1 10 swct1 11
Conti (Desirable if (swct11)
devct110 swct1 1
??? ??? ?? ??? ?? ???? if?? ????.
43
Desirable coding style

• Style 8 if ??? if? ???? ??? null else? ?? ?.
• Not Desirable
• if (qtygt10)
• if( qty gt 200)
• if (qty gt500) bill_a1.00
• else bill_a 0.50
• else
• else bill_a 0.0

44
Desirable coding style
Not Desirable get_t.ken () if (tkn
T_END) return / A / if (tkn
T_START) stant-proc () / B / while
(ntokens lt T_LIMIT) / C /
process_token () add_entry
get_t.ken () if (tkn T_END)
return if (tkn T_START)
stant-proc()
Style 9 ??? ??? ??? ??. ?? ??? ???? ??? ???
????? ???. ??? ???, break, continue,
return? ?? ?? ?? ??? ????.
Desirable
for ( ) get_t.ken() if
(tkn T_END) return if (tkn
T_START) stant-proc() if (T_LIMIT lt
ntokens) break process_token ()
add_entry
? ??? A, B, C? ???? ??? ?? ???? ??. While ??? ??
??? for ???? ??? ????? ? ??.
45
Programming Standards

• Standards can be both a blessing and a curse
• Modules of coincidental cohesion arise from rules
  like
• Every module will consist of between 35 and 50
  executable statements
• Better
• Programmers should consult their managers before
  constructing a module with fewer than 35 or more
  than 50 executable statements

46
Remarks on Programming Standards

• No standard can ever be universally applicable
• Standards imposed from above will be ignored
• Standard must be checkable by machine

47
Examples of Good Programming Standards

• Nesting of if statements should not exceed a
  depth of 3, except with prior approval from the
  team leader
• Modules should consist of between 35 and 50
  statements, except with prior approval from the
  team leader
• Use of gotos should be avoided. However, with
  prior approval from the team leader, a forward
  goto may be used for error handling

48
Remarks on Programming Standards

• The aim of standards is to make maintenance
  easier
• If they make development difficult, then they
  must be modified
• Overly restrictive standards are
  counterproductive
• The quality of software suffers

49
Code Reuse

• Code reuse is the most common form of reuse
• However, artifacts from all workflows can be
  reused

50
Conclusions