1 / 20

Programming Style

Programming Style. CSE 105 Structured Programming Language Presentation - 2. Thanks to Arie Rapoport, cs.huji.ac.il. Start. Word Counting (K n R – 1.5.4). state=OUT nl=nw=nc=0. #include <stdio.h> #define IN 1 /* inside a word */ #define OUT 0 /* outside a word */

yagil
Download Presentation

Programming Style

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 cis 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 #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 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 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 now = getDate() Compare if( checkdigit(c) ) … to if( isdigit(c) ) … Accurate active names makes bugs apparent

  9. Indentation Use indentation to show structure Compare 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 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 if( i < 100 ) x = i; i++; to if( i < 100 ) { x = i; } i++;

  12. Idioms Do not try to make code “interesting” i = 0; while( i <= n – 1 ) array[i++] = 1; … for( i = 0; i < n; ) array[i++] = 1; … for( i = n; --i >= 0; ) array[i] = 1; … for( i = 0; i < n; i++ ) array[i] = 1; 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. if( x > 0 ) if( y > 0 ) if( x+y < 100 ) { ... } else printf(“Too large!\n" ); else printf("y too small!\n"); else 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 { ... } Idioms

  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

  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! … // 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: • 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.

More Related