Documente Academic
Documente Profesional
Documente Cultură
Todd Littell
22SEP05
Basic Coding Practices
Maintain State Locally
//////////// Bad C //////////// Good C
int count = 0; int countTokens()
void countTokens() {
{ int count = 0
while (…) while (…)
++count; ++count;
} return count;
}
//////////// Bad Java //////////// Good Java
public class TokenCount public class TokenCount
{ {
public int count; private int count;
public String token; private String token;
}
public int getCount() { return count; }
public void setCount(int cnt)
{ this.count = cnt; }
}
Maintain State Locally (2)
//////////// Bad C //////////// Good C
typedef struct { typedef struct {
int count; int count;
char *token; char *token;
} TokenCount; } TokenCount;
TokenCount tcArray[1000]; static TokenCount tcArray[1000];
int tcArraySize = 1000; static int tcArraySize = 1000;
• If a file contains more than 300-400 lines of code, then refactor it!
• Be able to describe the purpose of your function in one sentence, and the purpose of your class
(or file) in one paragraph. If it seems complex to you (the programmer) then it is too complex and
needs refactoring.
• WHY?
Be Resource Conscious
•If an object (or function) opens (or allocates or reserves) a resource, then the same
object (or function) should release it.
• It is possible to write a bad (or good) program in any language. Some simple
practices can go a long way.
• Maintain a consistent style; not just naming/indentation, but also in how you code.
• Stay away from side-effects, and be explicit about any mutators you may have (i.e. in
function name & in comments).
• Use common idioms & practices. For example, for defining constants, macros, testing
code, assertion code, etc.
Language Basics
Review of Address Space
Unix/Linux Address Space
Stack
Stack Segment
Data Segment
Heap
Global Data
• Comes with powerful pre-processor (e.g. #include, #define, #if, #ifdef, etc.).
• Separate declarations in header files (.h) from definitions in (.c) source files.
• Typing is weakly enforced; especially with primitives. Anything can be cast into
anything else, basically.
• A better C.
• Separate declarations in header files (.hpp) from definitions in (.cpp) source files.
• Run-Time Type Information and Exceptions are available, but not equally supported
across compilers.
• Do NOT override operators (esp. new/delete), possibly with the exception of streaming operators
<< and >>.
• Follow the Law of the Big Three (reference): If you have a non-trivial dtor, then you must provide
a suitable copy ctor & assignment op. Or, you must hide them.
• Variable are either primitives or object references! All objects are allocated on heap. Only
primitives & references are on stack.
• Declaration is not separated from definition. Both go in one source file (.java).
• Pointer arithmetic does not exist, which makes for safer code.
• Throw RuntimeException for very common exceptions; else define and throw your
own app exception (that is not derived from RuntimeException).
• When the construction & initialization of an object is complex, then a factory method
is often used.
– Example: javax.xml.parsers.DocumentBuilder.parse(InputStream is) :
org.w3c.dom.Document;
• Design with layers. Layer N can only call functions/objects in layer N-1.
• Design with composition, not inheritance. Compose objects with aggregation, not
inheritance. Rules for inheriting B from A:
– An instance of B object will always be an instance of an A object.
– A B object is a special kind-of an A object.
– Never inherit for convenience (e.g. Stack inheriting from Vector is wrong!).
– Use roles idiom to handle multiple types, or types that can change over time.
• Class hierarchies tend to be flat, not deep. Common practice in C++ is to add a Root
class. (Not much method overriding actually happens).
Common Design Principles (2)
• KISS
• Object Models: An object model encapsulates objects & class hierarchies. Most common
notation: Unified Modeling Language (UML).
– Why? Because OO Programming Languages (OOPL) dominate software field.
– How? Use pencil & paper, or whiteboard, or Visio, or software (Poseidon, Rational Rose, etc).
– Notations: UML has taken over. OMT was predecessor in many ways.
– UML is a Swiss Army knife – many views supported for different stakeholders.