Topic: Function design (thoughts)

[Mark]

You kind of did, you're just following VB(A) naming conventions: IsArray, IsDate, IsEmpty ...

Maybe it's to much Python and C++ and PHP and PERL ...... *grin*

funny fact:
When I write something in C++ I compile it right from Vim using the builtin command "make". Well the other day I wrote a little autolisp routine and then ran "make" on it. "oop's that didn't work"

[MP]

I hear ya -- can't tell you how many times I've been coding basic and typed "(defun ..."

[JohnK]

As long as we are on the subject of args/vars:

If im actualy building true "suport procedures" like Marks "istext" example i usualy rely on scoping to handle my args/vars.

Forinstance:

Code: [Select]

(defun c:MyApp ( / ename textp)
  (while (not (setq ename (entsel "\nselect object: "))))
 ;; suport procedure
  (defun textp ( )
    (and
      (member
        (cdr (assoc 0 (entget (car ename))))
        '("TEXT" "MTEXT")
        )
      )  
    )

  (if (textp)
    (alert "Congrats! You selected some Text.")
    (alert "Nope!")
    )
  )

This makes it that much easier for me to read. (Look at my "if" vs this:
 (if (textp (car ename))
   ...
   )
 )

Using lexical scoping in your procedure design, i believe, is much easier to follow.

[MP]

To each their own, but I wouldn't code it like that myself, though I am a proponent of lexical scoping.

[JohnK]

Why?

[MP]

Primarilly code clarity and re-use.

[JohnK]

Re-use is the reason i use it.

Pulling that procedure out and trying to hack together an app is hard.  (Forces me to "Build" a procdeure and not "cut 'n paste" one.) I realise that my "worker procedures" could get a bit bloated this way (-ie. building built-in support procedures for each) but its worth the overall robust-ness i achieve.

[Kerry]

The ugly side to this can be the 'indiscriminate wrapping' I see sometimes.

Sorry but I don't understand.  
 <<<<

I have seen [ read as,  debugged others code ] that has taken this concept a little to far. Its a different issue if the wrapped routine is used more than once or if it has a significant purpose.  ... sort of negates the 'readability' aspect. .. but admittedly that was for code that I didn't originate, so a reasonable amount of mental gymnastics is expected.

 .... on the other hand, a 3 page function that has no white space for thought delineation, and no header comments [ I prefer those to in line comments, the code should speak to me ] and everything inline and questionable variable naming regimen is a completely different can of worms.

[Kerry]

... while [ sort of ] on the topic of debugging ..

I frequently will write a named routine just for testing, then include its code in line to reduce the necessity of passing variables to a helper.