From: David Flower on
In another thread, I suggested that programmers should avoid using
defaults when the same thing can be specified explicitly.

It seems to me that posters could create a list of such situations, so
here's a few to start off with.

1) Explicitly SAVE all variables that need to be saved, and no others.

2) Avoid using then left-to-right rule in the avaluation of
expressions (e.g. X/Y*Z)

3) Explicitly declare all relevant file specifiers (DISP=,FORM= etc.)

Let's have some comments and other examples

Dave Flower
From: Ian Bush on
As if by magic, David Flower appeared !

> In another thread, I suggested that programmers should avoid using
> defaults when the same thing can be specified explicitly.
>
> It seems to me that posters could create a list of such situations, so
> here's a few to start off with.
>
> 1) Explicitly SAVE all variables that need to be saved, and no others.
>
> 2) Avoid using then left-to-right rule in the avaluation of
> expressions (e.g. X/Y*Z)
>
> 3) Explicitly declare all relevant file specifiers (DISP=,FORM= etc.)
>

4) Type all variables

5) Where possible use Intent

Ian


From: Paul van Delst on
David Flower wrote:
> In another thread, I suggested that programmers should avoid using
> defaults when the same thing can be specified explicitly.
>
> It seems to me that posters could create a list of such situations, so
> here's a few to start off with.
>
> 1) Explicitly SAVE all variables that need to be saved, and no others.
>
> 2) Avoid using then left-to-right rule in the avaluation of
> expressions (e.g. X/Y*Z)

So ... X/Y*Z is looked upon with disfavour?

What about Z*X/Y? I evaluate that left-to-right too.

I think you may need to explicitly mention the word "parentheses" or "brackets" somewhere
in your spec. :o)


> 3) Explicitly declare all relevant file specifiers (DISP=,FORM= etc.)
>
> Let's have some comments and other examples
>
> Dave Flower
From: Paul van Delst on
Ian Bush wrote:
> As if by magic, David Flower appeared !
>
>> In another thread, I suggested that programmers should avoid using
>> defaults when the same thing can be specified explicitly.
>>
>> It seems to me that posters could create a list of such situations, so
>> here's a few to start off with.
>>
>> 1) Explicitly SAVE all variables that need to be saved, and no others.
>>
>> 2) Avoid using then left-to-right rule in the avaluation of
>> expressions (e.g. X/Y*Z)
>>
>> 3) Explicitly declare all relevant file specifiers (DISP=,FORM= etc.)
>>
>
> 4) Type all variables

Or: Always use IMPLICIT NONE.

>
> 5) Where possible use Intent

...to do...? What? For a set of rules to help code be more explicit, they sure aren't.

:o)

cheers,

paulv

p.s. Apologies. Late night, no coffee yet......
From: Gordon Sande on
On 2008-01-23 10:06:39 -0400, Paul van Delst <Paul.vanDelst(a)noaa.gov> said:

> David Flower wrote:
>> In another thread, I suggested that programmers should avoid using
>> defaults when the same thing can be specified explicitly.
>>
>> It seems to me that posters could create a list of such situations, so
>> here's a few to start off with.
>>
>> 1) Explicitly SAVE all variables that need to be saved, and no others.
>>
>> 2) Avoid using then left-to-right rule in the avaluation of
>> expressions (e.g. X/Y*Z)
>
> So ... X/Y*Z is looked upon with disfavour?

Isn't the problem that the two operators / and ** do not have universal
instant association rules. They should be made redundently clear by use
of adequate parentheses. Just a special case of if the default is
unclear to "non experts" then make it explicit. Remenber the code will
be read by some idiot. Typically the programmer about twenty minutes
in the future!

> What about Z*X/Y? I evaluate that left-to-right too.
>
> I think you may need to explicitly mention the word "parentheses" or
> "brackets" somewhere in your spec. :o)
>
>
>> 3) Explicitly declare all relevant file specifiers (DISP=,FORM= etc.)
>>
>> Let's have some comments and other examples
>>
>> Dave Flower