Topic: Lisp Code Formatting

[BIGAL]

Its hard to change after 30+ years of coding but I am always learning and people Lee show us how to do it right.

I do need to indent my code more often, but as compromise I group sequences of code so they are completing a task rather than just 1 after another which as you point out is very hard to read.

I do agree very much with item 3 use library functions often see code with lines and lines repeated so many times.

I am happy to recieve any comments and like my granfather told me "A man who never made mistakes never made anything"

Indented or not wrote this bracket checker about 20 yeras ago come in handy some times even if code is indented.

Code: [Select]

; simple check lisp code for brackets not pairing
; By Alan H

(defun c:chkbrk (/ opf bkt chekdfile rdctl wkfile currentln wln ltr ncln)

(setvar "cmdecho" 0)

(alert "\nlook at end of line")

(SETQ chekdfile (getfiled "Enter file name:" " " "LSP" 4))

(setq opf (open chekdfile "r"))
(setq bkt 0)
(setq blkl 0)
(setq rdctl 1)

(setq wkfile (open "c:\temp\wow.lsp" "w"))

(setq currentln "a")

(while (/= blkl 6)
(setq currentln (read-line opf))
(if (= currentln nil)(setq currentln ""))
(if (= currentln "")(setq blkl (+ 1 blkl))(setq blkl 1))
(setq wln currentln)                                                       

(while (/= wln "")
        (setq ltr (substr wln 1 1))
        (setq wln (substr wln 2))
        (cond ((= (ascii ltr) 34) (if (= rdctl 0)(setq rdctl 1)(setq rdctl 0)))
                ((and (= ltr "(")(= rdctl 1))(setq bkt (+ bkt 1)))
                ((and (= ltr ")")(= rdctl 1))(setq bkt (- bkt 1)))
                ((and (= ltr ";")(= rdctl 1))(setq wln ""))
                ;(t (prompt ltr))
        )
)

(setq ncln (strcat currentln ";" (itoa bkt)

(princ (itoa bkt))

(if (= rdctl 0) "string open" "")))
(if (/= currentln "")(write-line ncln wkfile)))

(close wkfile)
(close opf)

(prompt (strcat "open brakets= " (itoa bkt) "."))



(setq ang1 nil
      pt1 nil
      pt2 nil
      pt3 nil
      pt4 nil
      pt5 nil)

(princ)
)

; run on loading
(c:chkbrk)


[MeasureUp]

To Ben's question in #1 post.
IMO, "NotePad++" is a nice text editor. I agree with Grrr1337 and I do exactly what he points out here:

Just sharing my preference:

Although I know about that functionality to assign multiple variables to symbols in one go,
I always prefer'd to use multiple times the setq function so then I could easily trace whats being/or not/ localised.
By just double-clicking in the notepad++ it highlights multiple instances of that word. 

It would be more readable if you leave spaces between functions.
Shortening your code may also be an issue of "readable" when the code reached to hundreds of lines.
However IMO "readable" may be an arguable word when people have their own style of writing. If the code writer thinks his/her code is readable so it is readable because in many cases he/she is the only reader.

Also it is good practice for putting sidenote in your code.

HTH

[kdub_nz]

< ... >
I think from that book are listed the general accepted rules when coding, but you know everyone has different perception on the things (and with time it changes).

I'd be interested in knowing the items that you believe don't apply to Lisp.

.... and no, I don't know that " everyone has different perception on the things "

Regards,

[JohnK]

*grabs popcorn*

[Grrr1337]

< ... >
I think from that book are listed the general accepted rules when coding, but you know everyone has different perception on the things (and with time it changes).

I'd be interested in knowing the items that you believe don't apply to Lisp.

.... and no, I don't know that " everyone has different perception on the things "

Regards,

I ment that not everyone uses all the steps listed in that book...
When did you started learning lisp, did you immediately started manipulating assoc/nested lists?
Or like the most skipped #4 rule, got used localising for example 10 symbols and later with the time learned how to avoid that, then your eyes got used to list manipulation and never went back...
I'm still seein guys disregard that #4 rule, although their knowledge or experience - you can't judge them because the routine still works.
And maybe if you ask them why, they might tell you "thats my preference" - which would cover my "perceptions" statement.

Whats a good example for #9 rule?
Say a variable name "Column5_WidthBase" won't be confused.
Then in the code are localised or used such names in a list 12 more variables with similar names.
Personally I'd get lost along the long variable names, and would use acronyms instead (i.e. "c5wb") - now you might agree with this, but not everyone prefers it.

So.. if my "everyone has different perception on the things"  statement is wrong, then why not everyone would code like that:

Code - Auto/Visual Lisp: [Select]

1. (setq colprops
2.   '(
3.     (c1wb 5)(c2wb 6)(c3wb 7)
4.     (c1ht 1)(c2ht 2)(c3ht 3)
5.   )
6. )
7.  
8. (setq inputs '((width 6) (height 2) (thickness 1) (offset 6)))

And I also know a guy who writes very impressive routines - but its a nightmare when you try to understand his codes, because:
He uses a global variables between his functions and localises them in the end function,
which means that you have to continiously scroll over the thousand rows just to trace whats happening to a single variable.
Someone else could say "hey thats wrong, don't do it like that", but thats his perception.

That book is a good guide, but it won't make everyone write exactly or almost in the same way.
Else we would see shortcuts and perfection everywhere IMO. 

[JohnK]

FYI: kdub and I took the MIT Structure and Intreptation of Computer Programs course together. Although I believe he was a more advanced lisper then I before he enrolled though. Nested lists, trees, and etc was chapter two (covered almost right away) of our book.

[Grrr1337]

FYI: kdub and I took the MIT Structure and Intreptation of Computer Programs course together. Although I believe he was a more advanced lisper then I before he enrolled though. Nested lists, trees, and etc was chapter two (covered almost right away) of our book.

Good to know, John - I was just trying temporarily to switch his point of view.

[JohnK]

And that's easier then respecting his (by maybe accepting his information has value and asking a thoughtful question)?

[kdub_nz]

Grrr1337,

Something to chew on for a couple of days :

With your 'colprops' example.
Would you provide a comment somewhere in the source to explain /clarify the variable naming. ?

Would if be more efficient to name the variables appropriately and forgo the comments.
(side note : I've read code where the naming explanation and the names were not synchronized ... with the expected resulting confusion.)

Suitably named variables ( and methods) give you an immediate image of the intent without needing to do the mental translations.



//=====================

Please note. I'm not attempting to suggest that there is only one correct way to structure code.
Really, I don't give a fuck about how other people write their code.
At the end of the day the compiler or interpreter will be the final arbiter of correct code, but correct code and code that is a pleasure to look at and read can be very different things.


added.
The list I posted is titled "The Elements of Programming Style" not "The Rules for Code Structure" ... two different animals.

[Grrr1337]

FYI: kdub and I took the MIT Structure and Intreptation of Computer Programs course together. Although I believe he was a more advanced lisper then I before he enrolled though. Nested lists, trees, and etc was chapter two (covered almost right away) of our book.

I appreciate every opinion/code/thing written, regardless of the author's background so I (and anyone) could have that in mind, and I'm sorry if that looks different.
However you cannot control one's interests, so you cannot use a statement like this without approval:

Grrr1337, you did not offend me by not liking me or my code.

Simply because it sounds rude and its not true.

With your 'colprops' example.
Would you provide a comment somewhere in the source to explain /clarify the variable naming. ?

Yes, that would make the most from the code: Variable names, using acronyms and comments explaining the meaning.

Would if be more efficient to name the variables appropriately and forgo the comments.
(side note : I've read code where the naming explanation and the names were not synchronized ... with the expected resulting confusion.)

Suitably named variables ( and methods) give you an immediate image of the intent without needing to do the mental translations.

Thats what I tried to say: "Suitably named variables", for some its "Column5_WidthBase" for others "c5wb".
And like I said I'd prefer the acronym to not get lost in long variable names, however some might prefer the long version.

The list I posted is titled "The Elements of Programming Style" not "The Rules for Code Structure" ... two different animals.

Ok, maybe I misunderstood - its just most of the 'steps' sound like a rules. Apologies.

Please note. I'm not attempting to suggest that there is only one correct way to structure code.

This is what I'm trying to explain:
Readability of the code is different, depending on the reader/writer's perception - In order most easy evaluation of the interpreter thats in his head.
Thats why we see codes written with different styles.
 
Regards,

[BIGAL]

Just a throw away comment, I know I need to indent more, but some code provided uses Tab as the spacing and this has the effect on deep routines of almost making them unreadable as you can not work out where the right end is. 2 spaces works nice.