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

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

Program Style Readability Clarity Common sense Right focus

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

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 …

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

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

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

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’;

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);

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

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

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

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 { ... }

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

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

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 ) { … }

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;

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

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.