Fog Creek Software
Discussion Board




Writing Solid Code

Reading "Writing Solid Code" by Steve Maguire, how much of its examples is still relevant especially to malloc, memcpy etc.  Basically, it seems to me that knowing the language compilers, the laguage itself, libs  and everything else in detail, is a MUST-REQUIRED to wirte solid code.  But with the growing Libs of J2EE and .Net, how can one be able to master everything ?

In languages without pre-processors (#define), how do people write debug-only code beside this form?

if ( true == DEBUG )
{
  // Debug Code
}

I don't like it because it is still part of the production code.  With #define, the debug is a subsystem and it does not exist at all in the released version.  Is there any newer version of this kind of book ?

8-(
Wednesday, June 11, 2003

It may not be what you are trying to say, but C# <does> have preprocessor directives like #define and #if.

Sergio
Wednesday, June 11, 2003

Our debugging/quality strategy consists of unit tests and a good logging framework. I think it is fantastic and I believe beats using #ifdefs everywhere.

Most of our systems are server based, and we need the ability to look at debug info on a production system. We can do this. In addition, when debug info is switched off, there is no performance overhead.

The unit tests are there to thouroughly exercise methods/modules using various inputs before they go into production. In one of our products, they have already saved us the cost of writing them many times over. I am now convinced test driven development is the way of the future :)

Rhys Keepence
Wednesday, June 11, 2003

No idea bout .net, but if you have something of the form
static final boolean DEBUG = true;
if( DEBUG ) {
    // not compiled if DEBUG false at compiletime
}

I could have sworn that the Java lang spec either hints or guarantees this optimization, but I haven't been doing Java for a while so of course verify or ask around at usenet.  If you run an optimizer such as an obfuscator, you might get this too.

Of course as Rhys pointed out, people are more interested in things like JUnit than cluttering up code.

I remember Writing Solid Code not giving great advice.  At least not always.  If it left the impression that you need to start memorizing details, then it's really worth scrutinizing.  I mean, it's a lot easier to just have a reasonable understanding of what's available, understanding a layer or two beneath really helps, and then just looking up things on an as-needed basis.  Memorization can easily follow from this.

sammy
Wednesday, June 11, 2003

AspectJ ( http://www.aspectj.org ) offers a good alternative for Java.

It using Aspect Oriented Programming rather than macro preprocessing, so it is a little more difficult to learn by the effort is worth it.

Ged Byrne
Wednesday, June 11, 2003

I think "Writing Solid Code" is one of the most important books around. Some of the details regarding memory management etc. may not apply to a given language, but the book basically presents a way of thinking about programming. It boils down to paying attention to all the cruddy little details that bite you later when you don't pay attention to them.

(Besides that, Maguire can write well which is a sadly lacking quality in many writers cranking out Bible-sized tomes these days...)

Jeff Kotula
Wednesday, June 11, 2003

You might try taking a look at "The Pragmatic Programmer".

The authors take a language agnostic approach to writing better software. I'm just about finished with it and I rank it as one of the best software development books I've read; right up there with McConnell's "Rapid Development".

Mark Hoffman
Wednesday, June 11, 2003

*  Recent Topics

*  Fog Creek Home