[Jared Russell]

I subscribe to the philosophy that there is no single way to write good code - it all depends on how it will be used, re-used, modified, etc. Writing code for an F-22 is fundamentally different than writing code for a FIRST robot.

When writing code for FRC, I put tremendous emphasis on techniques that enable very quick code changes with a minimum of potential for new mistakes. In between two matches, if I need to disable a mechanism or alter autonomous mode, etc., I want to be able to get in there, find the part I care about, and have tools in place that will prevent me from doing something foolish.

To this end...

Giving good, informative names to all classes, methods, and variables goes a long way towards making code self-documenting.

Bad:
double Gyro.get();

Better:
double Gyro.getAngle();

Better yet:
double Gyro.getHeadingInDegrees;

When you read code written in this way, you don't need nearly as many comments to explain what you are doing, and it becomes quite obvious when you make a mistake. (Obviously, there's a fine line between being descriptive and re-writing the entire function in its name)

On top of that, I always name variables according to scope...

m_memberVariable (starts with m_ to indicate it is a member of a class)
k_someConstant (starts with k_ to indicate it is a constant)
l_someLocalVariable (starts with l_ to indicate it is local in scope to a given block)
g_someGlobal (starts with g_ to indicate it is a global variable)
a_someArgument (starts with a_ to indicate it is an argument to the current method)

There are likewise certain design patterns I like a lot, and others that I eschew in FIRST simply because they are less intuitive or compact.