portability & maintainability

[Wayne Throop]

> It is intersting to note in the discussions re short, longs etc. that
> portability seems to be regarded as a major reason-d'etre for much
> coding activity.
>
> All very well if portability can become ingrained in our way of thinking
> just as block-structuring has now become (to some), but it should be noted
> that in this big bad commercial world we (some of us) live in, very few
> software projects can afford to schedule "extra" time for designing in, and
> testing, the portability of code.

Good point.  But it is worth noting that almost all the things that
enhance portability also enhance maintainability.  Thus, the arguments
about "you should use short/long/whatever in way x because it will help
you in porting"  are alwo valid when cast as "you should use
short/long/whatever in way x because

  - it will help you when the compiler changes it's mind about something
    you took for granted
  - you will be able to change *your* mind about representations later
  - etc. etc.

So, even though many folks tend to focus on porting as the reason to go
for data-hiding, modularity, abstraction, and so on, these same things
are important even when the code is *never* to be ported, simply because
of improved maintainability.

Sadly, this is easy to overlook, since it it trades some effort *now*
for more effort *later*.  Many end up going for the quick fix, and pay
heavily for it when the bill comes due.
-- 
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!rtp47!throopw