Saturday, October 28, 2006

Best of the web roundup

The site "Software Development in the Real World" has a nice roundup of websites that emphasize good design and organization.

Thursday, October 26, 2006

Object Oriented Programming in C

There are several in the class that have "C" as their native language. How then can they map all of our discussions of object oriented programming to this "arcane" procedural, portable assembly. The answer may surprise you, "Object oriented programming is a state of mind." It's away of solving problems, not a language paradigm necessarily. Laurent Deniau illuminates Object Oriented Programming in C. Here is a lengthy, detailed manual for doing OOP in C by Axel-Tobias Schriener. Yet another useful resource .

Thursday, October 19, 2006

Code Style and Conventions

Code Style and Conventions should appear in your SDD. The central aims in devising a coding style for your projects is predictability and readability:

  • Predictability Can members of your group identify semantic features of the code at a glance. You should avoid bad variable names (a, f(), etc), instead use nouns for variables and verbs for functions (m_date, up_vector, computeLocalTime()). Use names to indicate member variables "m_date". If you are using set/get style for member variables, use those names "setTime(), getTime()"; make sure you have symmetry in your names too.

  • Readability Can you read the code and tell what it does. The pinnacle of readable code is Literate Programming, which intertwines documentation and source. You can move toward this without a special programming environment by enforcing good names, liberal use of space, and frequent English comments to lead the eye through the code.


Since many of you are using a web interface, be sure to have conventions for your HTML and style sheets, even if they are automatically generated.

Standard Java conventions.

Details on Naming Conventions.

An example style guide for Mozilla code practice. Note, this style assumes "C" code. Here is a more java friendly style guide called "Turbine".

An example of a code style enforcer for visual studio.

Tuesday, October 17, 2006

System Design Document (SDD)

The system design document will be a very important component of your system. Yet more writing! This document is designed for internal use, for your team. It plays an important role in system documentation and maintenance. A successful SDD will capture the design philosophy and system at a high level, as well as detailed object level descriptions. This document should reflect your requirements document, i.e. reference reqs by number, and identify how the requirements were captured by the system. Brad Appleton has a nice template for SDDs. One might consider using Doxygen to generate at least some of the SDD directly from the code comments.

Monday, October 02, 2006

Requirements Recap

Karl Wiegers has a nice article about Writing Quality Requirements. This article covers strategies for validating your requirements. Please pay attention to the section Reviewing Requirements for Quality.

Because the quality of any product depends on the quality of the raw materials fed into it, poor requirements cannot lead to excellent software.

Startup Myths

Thanks to Peter for this one.
Top 10+1 Myths
of Business Geeks, by Ron Garret covers a few of the common misconceptions about starting a tech business. A few items are bit contrived, but important points.

As Dwight Eisenhower said: plans are useless, but planning is indispensable.