Re: [boost] Boost Talk: "How I Code" (?)

Subject: Re: [boost] Boost Talk: "How I Code" (?)
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-02-24 14:27:48

Denis Shevchenko wrote:
>> I will add, libraries must be written for people to use, and only
>> incidentally for people to read. 

> Disagree with you, Vicente. I think that libraries must be written for
> people to use (this is certainly the most important thing) AND for
> people to read. IMHO, perfect library is clear for all: for users
> (interface) and for another developers (internal source code).

So there are some pretty clear tradeoffs between usability of library interfaces and readability of library code, particularly when it comes to generic programming.  SFINAE makes function declarations pretty darn hard to read, but it makes error messages easier to read.  Template meta-programming around generic interfaces makes library code hard to follow, but provides a service to the user that makes their code easier to write and read.  It comes down to priorities and tradeoffs.  Lack of readability of library code can be compensated for by excellent documentation.

My priorities generally fall into this order:

Schedule
Portability
Performance
Usability
Reduced Code Size
Testability
Readability

Schedule is king.  Other people may have a different order they prefer.  Sometimes I increase usability at the expense of performance or reduce code size at the expense of performance.  The order isn't absolute, but rather a qualitative notion of which priorities are given more weight in making tradeoffs during design.

The way I code: think four times, code once.  I think about my design goals (the priorities listed above) and how what I'm planning on coding relates to those design goals.  I make design decisions conscious of what problem I'm trying to solve and what problems I'm creating.  I think things all the way through up front before I start implementing.  I implement very fast.  I try to minimize the time I have to spend testing.  Ideally, I want to spend 80% of my time thinking about how to solve problems and only 20% solving them by coding, testing and fixing bugs.  I want to spend more time testing than fixing bugs and I want to spend more time coding than testing.  I don't refactor code, I prefactor code.  Once code is tested I only refactor it when there are bugs.  When faced with problem code I prefer rewrite it to be clean rather than clean up dirty code.  I only reuse code that is well tested, well designed and intended for reuse.  I minimize external dependencies, even on we designed and well tested modules.  The benefit of adding a dependency must greatly outweigh the cost.

The most important metric for quality of code is that it works correctly.  It is easy to take that for granted until you are faced with 50K lines of code bloat that is very readable and follows the OO-design-out-of-nowhere pattern but is riddled with bugs.  The code you never need to read is the most "readable" code there is.

Regards,
Luke