Re: 3vl 2vl and NULL

"Frank Hamersley" <terabitemightbe_at_bigpond.com> wrote in message news:R4BJf.10883$yK1.8133_at_news-server.bigpond.net.au...
> David Cressey wrote:
> > "x" <x_at_not-exists.org> wrote
> >
> >>I hope you don't think the project engineer should obey the construction
> >>workers !
> >
> > The case cited was one of the construction workers not obeying the
project
> > engineer.
>
> It was a bit more subtle than that - or the purpose of presenting it was!

OK, OK, I agree. My summary ignored the subtlety behind the case cited. But at least I was closer than the phrasing I corrected. Or so I think.
>
> The issue is that the air con dudes made their own decision because they
> felt they could.

Yes. And this raises a whole can of worms. Basically, the air con dudes were making a "trivial" alteration to the implementation, and therefore to the design intent, of the structural engineer. However, their alteration turned out to be not so trivial after all.

This brings me to the subject of in line comments in code. Good code doesn't need comments all over the place. Good code pretty much tells its own story, and the reader can follow the story and discern the intent behind the code, just by following the code.

But there are cases where the design intent is not obvious, even to the well versed reader. In those cases, a comment that makes intent completely explicit, can be enormously helpful.

In the case of the air con dudes, I wouldn't expect a comment regarding the intent behind the steel beam to have been engraved on the beam itself. But I wouldn't be surprised if good engineering practice might recommend a note on the blueprints stating that the intent was to eventually extend the building five floors upward, and not to mess up the beams.

I'd like to bring this back to the case at hand, but this post is long already.
>
> This is a latent risk factor in the MV arena where the programmer
> determines and can change the cardinality of a domain at will. Of
> course good programmers don't but ....
>

I see the risk factor as being one of recasting a simple element as a list consisting of only one element, and then extending the list. Is this what you were referring to above? Received on Sat Feb 18 2006 - 13:48:48 CET