Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
62 views

C Programming Style Notes: Compe375 Embedded Systems Marino Fall 2012

1. The document provides guidelines for writing clear and readable C code, including using descriptive names, consistent indentation, comments to explain complex code, and minimizing global variables. 2. Specific guidelines include placing opening braces in consistent formats, indenting controlled blocks, separating code into distinct units with whitespace, and preventing word wrap in comments or code. 3. Global variables should only be used when necessary to share information between functions, as they can introduce subtle bugs, while local variables are preferable when possible.

Uploaded by

a42ortiz
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
62 views

C Programming Style Notes: Compe375 Embedded Systems Marino Fall 2012

1. The document provides guidelines for writing clear and readable C code, including using descriptive names, consistent indentation, comments to explain complex code, and minimizing global variables. 2. Specific guidelines include placing opening braces in consistent formats, indenting controlled blocks, separating code into distinct units with whitespace, and preventing word wrap in comments or code. 3. Global variables should only be used when necessary to share information between functions, as they can introduce subtle bugs, while local variables are preferable when possible.

Uploaded by

a42ortiz
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 3

CompE375 Embedded Systems

Marino

Fall 2012

C Programming Style Notes


A C program is a collection of variables and f nctions! A partic lar application can be implemented "it# different programs$ t#at is$ "it# different collections of variables and f nctions! %rogram design is largely t#e process of selecting t#e variables and f nctions t#at "ill comprise a program! &#ere are a fe" generally accepted C programming design r les' 1! (ariables and f nctions s#o ld be given names t#at s ggest t#eir role in t#e program! )&#is "ill ma*e t#e program easier to read and nderstand!+ 2! ,ocal variables s#o ld be sed in preference to global variables nless t#ere is a good reason for sing a global variable! )-lobal variables invite errors beca se t#ey are accessible to all f nctions!+ 3! &#e primary criteria for selecting t#e partic lar f nctions and variables sed to implement an application is simplicity! A program s#o ld be as easy to read and nderstand as possible! A C program may also be regarded as a te.t doc ment! &#at is$ t#e f nctions and variables t#at comprise a program are represented sing te.t! /n addition to t#e above program design r les$ t#ere are also programming style r les )or g idelines+ for constr cting t#e te.t doc ment t#at represents t#e program! Most of t#ese r les involve t#e se of 0"#itespace1$ t#at is$ t#e se of spaces$ tabstops$ and ne" lines to gro p te.t c#aracters into meaningf l nits! Follo"ing are some generally accepted programming style g idelines! Controlled 2loc*s A 0controlled bloc*1 is a gro p of statements t#at is controlled by a 3 alifying condition in a selection or iteration str ct re )follo"ing *ey"ords if$ else$ "#ile or for+! &#e compiler identifies a controlled bloc* sing c rly braces )"#ic# may be omitted if t#e controlled bloc* #as a single statement+! 4#itespace s#o ld be sed in addition to c rly braces to #elp t#e reader identify a controlled bloc*! 5elated style g idelines are' 2e consistent in t#e se of c rly braces! &#e opening c rly brace s#o ld be eit#er after t#e *ey"ord p#rase$ for e.ample if () { or directly belo" t#e first letter of t#e *ey"ord on t#e ne.t line$ for e.ample if () { %ic* one and se it consistently! /ndent all statements in t#e controlled bloc* by t#e same amo nt! &#e amo nt of indentation s#o ld be 2$ 3 or 6 spaces! 2 t again$ be consistent )e!g!$ al"ays indent a controlled bloc* by 3 spaces+! &#e closing c rly brace s#o ld be directly belo" t#e first letter of t#e *ey"ord! (ertical 4#itespace )ne" lines+ 7se vertical "#itespace to separate parts of a program into distinct nits! For e.ample$ s*ip a line before and after eac# f nction definition! S*ip a line before and after t#e declaration of a gro p of global variables! 8o not se vertical space indiscriminately! /t "ill lose its meaning!

CompE375 Embedded Systems

Marino

Fall 2012

Comments (ariable names and f nction names s#o ld be "ell9c#osen! :o"ever$ "#en t#e tas* a f nction performs or t#e p rpose of a variable is not clear from its name$ incl de an e.planatory comment! 4#en t#e p rpose of a section of code is not clear to t#e e.pected reader$ incl de a comment! Adopt a consistent style for ma*ing clear to t#e reader "#at statement)s+ a comment applies to! For e.ample$ if a comment applies to a gro p of statements$ p t t#e comment on a separate line before t#e first statement$ and s*ip a line after t#e last statement! Font 7se a fi.ed "idt# font$ t#at is$ a font in "#ic# eac# c#aracter #as t#e same "idt# )e!g!$ Co rier$ Co rier ;e"$ Consolas$ Monaco$ , cadia Console+! Code lines p vertically in a more readable fas#ion! For e.ample$ a list of 69digit #e. n mbers "ill all be t#e same "idt# "it# a fi.ed9"idt# font! fixed width: 0xABCD 0x1111 0x1CC1 not fi.ed "idt#' 0.A2C8 0.1111 0.1CC1

4ord"rap in %rinted 8oc ments 8o not allo" "ord"rap to contin e a line of code or a comment on t#e ne.t printed line! /nsert ne"lines into t#e code or comment to prevent t#is from occ rring -lobal (ariables A local variable of a f nction is a parameter variable of t#e f nction or a variable declared "it#in t#e f nction! A global variable is a variable declared o tside of any f nction! &#e scope of a variable is t#e collection of statements t#at are allo"ed to refer to t#e variable! &#e scope of a local variable is t#e bloc* of statements t#at define t#e f nction )i!e!$ bet"een t#e opening c rly brace of t#e f nction and t#e closing c rly brace+! &#e scope of a global variable is t#e entire program )ass ming a single so rce mod le+! &#at is$ statements in any f nction can refer to a global variable! &#e duration of a variable is t#e time d ring "#ic# t#e variable e.ists in memory! &#e d ration of a local variable is from t#e time t#e f nction is called ntil t#e f nction ret rns! &#e d ration of a global variable is from t#e time t#e program loads ntil e.it from t#e program! &#e ad<ective static$ "#en sed in t#e declaration of a local variable$ increases t#e d ration of t#e variable' t#e variable e.ists from t#e time t#e f nction is first called ntil t#e program e.its= it is initiali>ed on t#e first call to t#e f nction$ and t#ereafter #as t#e val e last assigned in any e.ec tion of t#e f nction! -lobal variables are sef l beca se t#ey eliminate t#e need to pass information sing parameter variables! /n embedded systems programming t#ey are sed more often t#an in application programming beca se it is often convenient?necessary for an interr pt service ro tine

CompE375 Embedded Systems

Marino

Fall 2012

to access a variable t#at m st also be available to ot#er f nctions in t#e program! /t is also possible t#at t#e deb gging capabilities of t#e /8E are better for global variables! ;evert#eless$ global variables s#o ld be sed sparingly beca se t#ey are prone to s btle b gs t#at occ r "#en a global variable c#anges ne.pectedly= finding "#at f nction is c#anging t#e variable can be problematic! /n general$ global variables s#o ld be sed only be sed if t#e information represented by t#e variable is needed by m ltiple f nctions$ and passing t#e information sing parameters is nnecessarily c mbersome! A global variable s#o ld never be sed for local tas*s s c# as inde. variables for stepping t#ro g# an array or variables for controlling loops!

You might also like