Wednesday, February 24, 2010

Enforce Idioms - Get Religion

In the last series of articles we talked about how consistent coding style and great documentation can help a code base stay manageable. Beyond coding style and documentation, I think the most important thing Project 2 could have done would be to clearly define the coding idioms they deemed to be important.

Idioms and coding religion are a great way to boil down the things that the designers, architects and programmers of the original code base deem to be important. Some things are about how code should be written and others are related to business aspects of the project. Often they reflect, at a code level, what the functional specifications of the project are. They all should be addressed as early into the project as possible.

Perhaps you are making a web framework? What are the important characteristics that framework should exhibit. Look at how Django and Rails have defined their design philosophies.

What if you are making an asynchronous communications library? Look at what Ice deems to be important. Compare this to the Twisted library.

What if you are writing a programming language? Then perhaps a whole other set of things are important to you? Consider The Zen of Python.

Just will a little thought (and a couple of beers) I assembled this short list of things I view as important considerations when tackling a software project.

  • Low Coupling, High Cohesion
  • Less code
  • Quick development
  • Don't Repeat Yourself
  • Explicit is better than Implicit
  • Consistency
  • Prefer Stateless Classes
  • Separate Logic from Presentation
  • All Code must have Tests
  • Internationalization must be addressed in all cases
  • MVC
  • SOA (RESTful?)
  • Getting Real - https://gettingreal.37signals.com/
  • Convention over Configuration - No XML Situps
  • Principle of Least Surprise
  • Principle of Least Knowledge
  • What are the accepted licenses
  • What are the accepted libraries
  • What are the accepted languages
  • No commented out code
  • Remove dead classes
  • Compile Clean
  • Prefer Data Driven Design
  • Don't treat Exceptions like Booleans
  • Don't Mask Exceptions
  • Know your Exception Hierarchy
  • Prefer Aggregation over Inheritance
  • Prefer Event-driven over Multi-threaded (or vise-versa)
  • Prefer Reaping over Explicit Deletion
  • Prefer Immutable Data
  • Prefer Finite State Machines to Boolean Nests
  • No Switch Statements
  • No Singletons (includes Globals)
  • No “Regions” in C#
  • Avoid state / Offload state to the caller
  • Cache everything / Cache nothing
  • Prefer Lazy-loading / Lazy initialization
  • Don't make up new names for accepted practices
Now I'm sure some of you are looking at this list and going “Well, duh!” but don't laugh too soon. You would not believe how many of these common sense coding philosophies are violated daily. If anything these rules can serve as a training tool for new developers to learn the difference between good and bad code. Reviewing one ortwo of these during lunch sessions is a great way to ramp up your teams overall coding skills.

I'm sure, even without a few beers, you could add a ton of your own rules to this list. The c2.com website is a great place for ideas and discussion.

The question is … how many rules should you set?

The answer is, of course, it depends. If you are running an open source project and are looking to recruit more developers onto your project, then perhaps you don't want too many barriers to adoption. If you are in a corporate environment and give RCS commit privileges immediately to new hires (bad), you might want to set more ground rules.

Just be aware of one important thing: When you add or change a rule, you instantly incur technical debt! If it was previously acceptable to mask exceptions and then you set a project rule that exceptions cannot be masked, you just took on a chunk of technical debt. Your first step in adopting this rule has to be cleaning up the debt. Don't start building your church with broken windows.

If your programmers can follow and maintain an agreed upon set of programming idioms you are likely well on your way to producing a beautiful body of code.

Knowing this sort of thing comes from experience. Next time we will talk about developer skills and what the good ones seem to have in common.

No comments: