Loading ...
Sorry, an error occurred while loading the content.

Good Design -- is it relative?

Expand Messages
  • Ron Jeffries
    ... I ve though long and hard about this guy s view. It could just be that I m insufficiently post-modern to get it. Granting that possibility, I actually
    Message 1 of 139 , Nov 30, 2002
      Around Thursday, November 28, 2002, 3:58:34 PM, Dale Emery wrote:

      > Hi Ron,

      >> > Hmm, there was a _loong_ thread that you started by asking what
      >> > was "Good Design", I never saw your summary of that. I take it
      >> > this book in progress is perhaps that?
      >> No. That inquiry (which I think I did actually sort of summarize
      >> once upon a time) didn't produce much. Good design is modular, high
      >> cohesion, low coupling. Most people think good design is what you
      >> do, not the result. As if given two identical programs, one which
      >> was just coded up, and the other of which was created using "good
      >> design techniques", only the second one would have a good design.

      > There was also one guy who insisted ad nauseum (and *continues* to
      > insist ad nauseum, apparently) that "good" is meaningful only when you
      > know what problem the designers were trying to solve. It's that
      > problem, and only that problem, that defines what good means for a
      > given design. (At least, that's what that guy insisted.)

      I've though long and hard about this guy's view. It could just be that
      I'm insufficiently post-modern to get it. Granting that possibility, I
      actually think that there are things that can be said about good
      design [nearly] independent of context.

      What I mean by that is that there are some "rules" which, if we find
      them broken, should at least inspire us to ask, "Is there some special
      reason why?" There could be reasons. Here are some questions and
      example reasons:

      Is there some special reason why this code ...

      Uses symbols like a, b, i, j, j1, j2 instead of meaningful names?

      This is an implementation of a well-known mathematical formula
      that uses those very symbols;

      Follow-up Question: Would it be useful to put a reference to
      this fact in the code for those to whom the formula isn't quite
      so well-known?

      This code runs on a computer where the symbol table is stored in
      memory as the program runs, and it has very limited memory.

      Follow-up Question: Have you considered writing the code with
      meaningful symbols and then doing a machine substitution right
      before compiling?

      Has these three functions mushed together into one instead of broken
      out as three meaningful concepts?

      This code has to run in 13 microseconds and so the time to call
      three functions, which we measured to be 3 microseconds each, was
      too much.

      Follow-up Question: why not express the three functions as open
      functions (macros) in that case?

      Has this one big class with at least two visible and very different

      Has these two classes that seem to be dividing up information that
      belongs together?

      In short: it seems to me that certain design principles, notably good
      naming, high cohesion, low coupling to name a few, are close enough to
      universal that their absence ought at least to trigger exploration.

      Most of the times I have seen these principles violated, there was no
      good technical reason for violating them. There may have been human
      reasons such as:

      We thought it would be quicker to program with short variable names.

      We wrote the code inline and it was working so we didn't see the
      value to breaking it up.

      We had to decompile from binary because we lost the source code.
      Those are the names that the decompiler created.

      One of our programmers speaks English, one Tagalog, one Chinese, and
      one Inner Qwghlm, so the only variable names they have in common are
      single letters.

      What says "this guy" to that?

      Ron Jeffries
      To be on the wire is life. The rest is waiting. --Karl Wallenda
    • J. B. Rainsberger
      So said ericheikkila on 12/4/2002 -------------------- ... Often, i means something. Say what you mean; mean what you say. :) J. B. Rainsberger,
      Message 139 of 139 , Dec 7, 2002
        So said ericheikkila on 12/4/2002 --------------------

        >Single letter variables drive me nuts. ;)
        >I use 'index' instead of 'i' (or loop, or maybe count, depending on
        >the context).
        >As far as abbreviations go...if the entire team agrees, fine.
        >If someone on the team doesn't know that itr is the same as iterator,
        >just change it to iterator.
        >Usually, I'll not abbrev ;)

        Often, "i" means something. Say what you mean; mean what you say. :)

        J. B. Rainsberger,
        President, Diaspar Software Services
        Let's write software that people understand.
        telephone: +1 416 791-8603
        All correspondence (c) 2002 Diaspar Software Services.
        If you want to use it, just ask; don't steal.
      Your message has been successfully submitted and would be delivered to recipients shortly.