Good Programming and Good Programming Languages

 The Executive Summary

"Good" code has two features:

(1) Disciplined developers. The most important factor.  Their most important rule is The Boy Scout Principle: Leave it better than you found it.

(2) A disciplined language.  There are lower limits: for example, BASIC doesn't cut it.

The High Level View

Think: How Would You Build a City?  By separation of concerns; i.e., Abstraction and Modularity.

Good code is broken into subsystems (modules, classes, whatever) which are "loosely coupled".

Subsystems DO ONLY ONE THING AND DO IT WELL.  Some call this the "Single Responsibility Rule".

Subsystems (once tested and finished) should NOT BE MODIFIED: instead, write a new subsystem ("extension") that uses the subsystem (via abstraction!) and changes or extends its functionality.  Some call this the "Open/Closed Rule".

Dependencies (ideally) ought to be managed through abstractions; i.e. "code to interfaces".

Messy Details

Functions and classes should be small (i.e. "do only one thing and do it well").  When a thing loses cohesion, split it up.  Yes, this will increase the overall code length -- but usability, readability, and maintainability all go up.

A symptom of functions doing multiple things is the passing of flags as parameters.  Passing a boolean into a function is generally horrible.

DRY ("Don't Repeat Yourself").

The Principle of Least Astonishment applies to functions, classes, etc.

We all know that data should be hidden, right?  (Law of Demeter).

Use Unchecked Exceptions and please avoid Checked Exceptions as much as possible.

Write tests for 3P code you use (no, really!  Can you think of two reasons why?)

Test-Driven Development saves you from the temptation of massive "improvements" which ruins the code... by forcing Incremental Changes.

Building or Testing should be runnable with just one command.

Polymorphism is better than if or switch.