Re: 3vl 2vl and NULL

David Cressey wrote:
> "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
>>>
[..]
>>
>>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.

Understood.

>>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.

I reckon the penny might have dropped before they finished the job but after the irreversible damage was done. I suspect the core drillers would have been bitching about the amount of and guage of steel reinforcing they had to cut through - but its all too late by then!

> 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.

I am at odds with you here - I am a heavy commentator even in code I know only I will maintain.

Firstly "Good code" as you typify it may well tell its own story but then every reader is faced with reading form the top to build up the context. This is not efficient when the second and subsequent versions are being developed or new programmers tasked with changing it. Of course at Uni we were encouraged to produce very small chunks of code such that it would be easy to confirm its correctness before they were combined to produce higher level small chunks. However in practice that goal is not always achieved and comments become very useful.

Secondly, just because the code tells its story, it does not prove it has delivered the designers intent. I see comments as a locally based counterpoint to test that story and aid me in assessing whether the programmer got the right message.

> 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.

Yes in an ideal world, but for practical reasons the plans for each floor are issued on the basis the architect has addressed inter-floor coherency. Overlaying a future agenda prolly raises more risk in making the drawings more complicated than they need to be for the job at hand.

> 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?

In a general sense yes - because a free rein exists on cardinality, there will be some cases where programmers will adjust it to suit their immediate interest, rather than taking a longer term corporate view.

Cheers, Frank. Received on Sun Feb 19 2006 - 03:46:06 CET