1. CSE 105 Structured Programming Language Presentation - 2
Programming Style
CSE 105
Structured Programming Language
Presentation - 2
Thanks to Arie Rapoport, cs.huji.ac.il

2. Word Counting (KnR – 1.5.4) #include <stdio.h>
Start
Word Counting (KnR – 1.5.4)
state=OUT
nl=nw=nc=0
#include <stdio.h>
#define IN 1 /* inside a word */
#define OUT 0 /* outside a word */
/* count lines, words, and characters in input */
main( ) {
int c, nl, nw, nc, state;
state = OUT;
nl = nw = nc = 0;
while ((c = getchar()) != EOF) {
++nc;
if (c == ‘\n‘)
++nl;
if (c == ‘ ‘ || c == ‘\n‘ || c == ‘\t‘)
sate = OUT;
else if (state == OUT) {
state = IN;
++nw; }
printf(“%d %d %d\n”, nl, nw, nc);
c = getchar()
c != EOF N Y
++nc;
c==‘\n‘ Y N
++nl
c is
white-
char
state==
OUT N Y Y
state = OUT
state=IN
++nw
print nl,nw,nc
End

3. Program Style
Readability
Clarity
Common sense
Right focus

4. What’s in a name Example More reasonable #define ONE 1 #define TEN 10
#define TWENTY 20
More reasonable
#define INPUT_MODE 1
#define INPUT_BUFSIZE 10
#define OUTPUT_BUFSIZE 20

5. What’s in a name Use descriptive names for global variables
int npending = 0; // current length of input queue
Naming conventions vary
numPending
num_pending
NumberOfPendingEvents …

6. What’s in a name Compare and Use short names for locals
for( theElementIndex = 0;
theElementIndex < numberOfElements;
theElementIndex++ )
elementArray[theElementIndex] = theElementIndex;
and
for( i = 0; i < nelems; i++ )
elem[i] = i;
Use short names for locals

7. What’s in a name Consider The word “queue” appears in 3 different ways
int noOfItemsInQ;
int frontOfTheQueue;
int queueCapacity; …
The word “queue” appears in 3 different ways
Be Consistent
Follow naming guidelines used by your peers

8. What’s in a name Use active name for functions Compare
now = getDate()
Compare
if( checkdigit(c) ) … to
if( isdigit(c) ) …
Accurate active names makes bugs apparent

9. Indentation Use indentation to show structure Compare to
for(n++; n <100; field[n++] = 0);
c = 0; return ‘\n’; to
for( n++; n <100; n++)
field[n] = 0;
c = 0;
return ‘\n’;

10. Expressions Use parenthesis to resolve ambiguity Compare to
leap_year = y % 4 == 0 && y %100 != 0
|| y % 400 == 0; to
leap_year = ((y % 4 == 0) && (y %100 != 0))
|| (y % 400 == 0);

11. Statements Use braces to resolve ambiguity Compare to if( i < 100 )
x = i;
i++; to { }

12. Idioms Do not try to make code “interesting”
while( i <= n – 1 )
array[i++] = 1; …
for( i = 0; i < n; )
for( i = n; --i >= 0; )
array[i] = 1;
for( i = 0; i < n; i++ )
Explain idioms as patterns for writing code in the programming language, a.k.a. conventions
This is the common “idiom” that any programmer will recognize

13. Idioms Use “else if” for multi-way decisions if ( cond1 ) statement1
else if ( cond2 )
statement2 …
else if ( condn )
statementn
else
default-statement

14. Idioms if( x > 0 ) if( y > 0 ) if( x <= 0 )
if( x+y < 100 ) {
...
} else
printf(“Too large!\n" );
else
printf("y too small!\n");
printf("x too small!\n");
if( x <= 0 )
printf("x too small!\n");
else if( y <= 0 )
printf("y too small!\n");
else if( x+y >= 100 )
printf("Sum too large!\n" );
else {
... }

15. Comments Don’t belabor the obvious
// return SUCCESS
return SUCCESS;
// Initialize “total” to “number_received”
total = number_received;
Test: does comment add something that is not evident from the code
The best documentation is a good code styling

16. Comments Document each function
// random: return a random integer in [0..r]
int random( int r ) {
return (int)floor(rand()*r); }

17. Comments A more elaborate function comment //
// GammaGreaterThanOne( Alpha )
// Generate a gamma random variable when alpha > 1.
// Assumption: Alpha > 1
// Reference: Ripley, Stochastic Simulation, p.90
// Chang and Feast, Appl.Stat. (28) p.290
double GammaGreaterThanOne( double Alpha )
{ … }

18. Comments Don’t comment bad code – rewrite it! Instead …
// If result = 0 a match was found so return
// true; otherwise return false;
return !result;
Instead
return matchfound;

19. Style recap Descriptive names Clarity in expressions
Straightforward flow
Readability of code & comments
Consistent conventions & idioms

20. Why Bother? Good style: Sloppy code bad code Easy to understand code
Smaller & polished
Makes errors apparent
Yields a good grade
Sloppy code bad code
Hard to read
Broken flow
Harder to find errors & correct them, maintenance.