Proper coding

[kai]

I just came across a function that again made me think that we should not do this and yet people keep doing it anyway.

Note that this is just an example. You find plenty of similar code elsewhere.

This is the function I am complaining about:

Code: Select all

 ok←canDoit;t;⎕USING
     ⍝ Verify the user has access to rewrite the files:
     ⍝ Try to create a file
 :Trap 19 22
     t ⎕NERASE(t←SALTDir,'/deletethis')⎕NCREATE ok←0
     ok←1
 :EndTrap

The problem I run into was that the function returned a 1 and yet all later attempts to replace any of the SALT-related functions fail with error 19 (ACCESS ERROR). So I had to find out what was going wrong.

The way the function is coded made it impossible to trace through it and check what's going on. And that's my point.

As far as I am concerned the biggest advantage of APL over other programming languages is how easily I can trace through code, find out what's wrong and make amendments along the way.

We can however code in a way that makes that harder then necessary. The function above is an example: trying to create and delete a file on one single line is a bad idea.

For the same reason it is a bad idea to tie, read and untie a file on a single line. All well and good as long as it works but just simply bad when it stops working.

Another example is a construct like this:

Code: Select all

:If condition ⋄  flag←1  ⋄  :EndIf

In the tracer you cannot see whether "flag" was set or not. What's the point of using a control structure then?!

My suggestion: always code with tracing code in mind because the likelihood is that sooner to later you have to trace through that code.

[gil]

This is coming from the guy who tried:

      flag←⍣condition⊢1

;)

[kai]

Ahem... no comment.

[ArrayMac227]

Despite being wary when I see any topic of the form 'Proper...' I have some thoughts:

The problems with tracing through certain constructions: control structures, and formerly, I think, d-fns, are a property of the IDE, not the language.

I do wonder if flag←condition would work here, as it might not, if the intent was to leave 'flag' unchanged when 'condition' was 0.