Author Topic: Questions for the experienced programmers  (Read 3431 times)

0 Members and 1 Guest are viewing this topic.

Grrr1337

  • Swamp Rat
  • Posts: 783
Questions for the experienced programmers
« on: September 30, 2016, 03:01:31 PM »
Hi guys,
I have some questions:
With the time I gain more experience/skill writing lisp codes, but additional problems came up - the last written codes are becomming longer and longer, and harder to debug.
I tried to reduce this syntax identing/unfolding (not sure how its called - 'stacking the syntaxes' I guess) so the formatting would be worse, but that way I could see more lines of the code at the monitor. I've seen that its more important to structure the whole program into "blocks", and define more subfunctions to reduce the main program's length.

1. So what would be the best way to structure very long program?
2. How you deal with very long codes (where you have to scroll several times, to see the matching closing parenthesis/syntax) ?
3. Overall, how do you understand whats happening, when you strike a error upon loading, which could not be fixed with Vlide->Debug->Last Break Source (because its some syntax error - where somewhere in your code you misplaced the opening and closing syntax - and you have to find the problem 'manually')


Personally, as I said I started to organize the program structure into such "blocks" (the programming term). And when I have to find any problem manually, I start to "comment" blocks of the program (using remove-until-find method) to determine inside which "block" the program fails.
Do you have any additional advices?

Say syntaxes in your code go like this (and I consider it as a mid-long code):
Code: [Select]
( ()
(
)

(
(
(
(
(
)
)
)
)
)
(
(
)
)
()
(
(
(
(
)
)
)
)
(
)
(
)
(
(
(
(
(
(
(
(
)
)
)
)
)
)
()
)
(())
)
(
(
(
(
(
)
)
(
(
(
(
)
)
)
)
(
(
)
)
)
)
)
()
)
And heres what I mean, by re-structure such as "block" use:
Code: [Select]
( ()


()
(( ; Block #1
(
(
(
)
)
)))
(())


()
( ; Block #2
(
(
(
)
)
))
()
()


( ; Block #3
(((
(
(
(
(
)
)
)
)
))())(()))


( ; Block #4
(
(
(())
(
(
(
(
)
))
)
(
(
)
))
)
)
()
); defun
(apply ''((a b c)(a b c))
  '(
    (( f L ) (apply 'strcat (f L)))
    (( L ) (if L (cons (chr (car L)) (f (cdr L)))))
    (72 101 108 108 111 32 87 111 114 108 100)
  )
)

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: Questions for the experienced programmers
« Reply #1 on: September 30, 2016, 03:23:00 PM »
Sitting in a dentist chair so briefly -- employ DRY principle, write atomically (functions perform one task) and clear code is better than clever code. Finally, document as if you won't see your code for a year -- high level (intention) comments are generally more useful -- and necessary -- compared to low level comments which are usually not necessary if one employs descriptive names for functions and variables.
Engineering Technologist CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com http://cadanalyst.slack.com http://linkedin.com/in/cadanalyst

ribarm

  • Gator
  • Posts: 2829
  • Marko Ribar, architect
Re: Questions for the experienced programmers
« Reply #2 on: September 30, 2016, 03:54:33 PM »
Hi Grrr, I'll just say what I think so don't consider it as must... I tend to use just 2 spaces when structuring loops and blocks of codes... I use Notepad ++ for quickly move blocks from left margin (edge) of code using setting of 2 spaces as TAB formatting... I don't see why Lee Mac uses 4 spaces and in your example there is also plenty of room, so it's just personal structuring habit... Although it's not necessity like irneb stated it's quicker to close brackets in the same line of paragraph, but I don't like it much - then I don't see code elegant structured in blocks and I tend to avoid such situations... Notepad ++ have also ability to mark open bracket with closing one so it's easy to see where the problem may occur... Also when checking for parentheses it's nice to use sometimes VLIDE editor and mark blocks of code from end up to beginning of code... Then you can bump into unbalanced matching of brackets more reliably... But beside nice look of coding that's not the most important thing when coding bigger lisps... The most important thing is that the routine works as expected... There are quite lot of thing that may happen when debugging : typo mistakes, evaluation of variable as nil which will produce error in next coded syntax, sometime it's good to step from parametric programming - I mean using formulas to numerical coding, and sometimes it's totally opposite you need to convert hard coded numbers into parametric formulas... For me it's the hardest bug to find where was wrong evaluation when last break point is inside sub function, so you can't step backwards to see when sub function was called ( was it early or somewhere in the middle of code or the problem appeared near end of routine )... For this you have to have intuition and experience to have correct assumption and to find where the problem was... Almost all codes that have considerable length won't work from first testing attempt... So the most important thing is that when you coded much to be concentrate and patient - not to give up and leave bug to be unsolved... You have to be very persistent in debugging and like others stated it's important to know where to put break points while checking problematic portion of code... Animation option is useful too, but more important is to be sure what routine is doing from beginning to the end and to spot where such problematic portion of code was written to correctly set break point before it, then use inspect tool and watch window with all necessary variables filled in window and analyze what returns are... Sometime the problem is in sub function that is correct but for different routine and in your new routine it needed to be modified to suit different algorithm processing... And so much more can be discussed on it, but like MP stated and I agree 100% with it when it works, it works and beauty of coding may be or not pretty to someone or not, but functionality isn't questionable when it works as it should...
Marko Ribar, d.i.a. (graduated engineer of architecture)

:)

M.R. on Youtube

kdub

  • Mesozoic keyThumper
  • SuperMod
  • Water Moccasin
  • Posts: 1508
  • class keyThumper<T>:ILazy<T>
Re: Questions for the experienced programmers
« Reply #3 on: September 30, 2016, 04:32:27 PM »
At the risk of repeating advice given  ....

You'll probably spend 10 times as long reading code as you will writing it, so make sure it's readable FOR YOU.

Functionally it doesn't matter a rats tail. Aesthetically it will matter to YOU. ( or it should )

At this stage you should have read enough code to know what you like the look of and know what is easy to read .. use that experience.

My recommendation is to use one of the formatting styles available in the VLIDE.
If you post code that has an unusual, unique set-out style chances are I'll ignore it (as in not bother to read it) or re-format it in the IDE I'm using.

If you stay with programming you'll get more benefit from breaking your code down into smaller individual functions and using suitable function and variable names than you will by worrying about formatting.

Something that is important to me is to ensure that the reader gets a chance to take a breath when reading my code.

Regards,







called Kerry in my other life

Sometimes the question is more important than the answer.

I don't really work crazy hours . . I just live at UTC + 13.00
#ridesober

Grrr1337

  • Swamp Rat
  • Posts: 783
Re: Questions for the experienced programmers
« Reply #4 on: September 30, 2016, 05:18:50 PM »
I forgot to mention that I'm notepad++ guy aswell,
So I follow most of the stuff marko_ribar wrote (including partially debugging in VLIDE).
NPP++ seems quite flexible as it goes to formatting - compared with VLIDE, but I'm considering almost full transition as it seems its the best debugging tool for AutoLISP.
Still I'm not sure how one deals with half-a-meter long code without getting lost (I'm not there yet, but its good to be prepared).
I'll re-read your advices incase I missed something, thank you gentlemen!
(apply ''((a b c)(a b c))
  '(
    (( f L ) (apply 'strcat (f L)))
    (( L ) (if L (cons (chr (car L)) (f (cdr L)))))
    (72 101 108 108 111 32 87 111 114 108 100)
  )
)

JohnK

  • Administrator
  • Seagull
  • Posts: 10170
Re: Questions for the experienced programmers
« Reply #5 on: September 30, 2016, 06:00:30 PM »
Typing this on my phone so I apologize for being brief.

In some languages you break a program into several files -i.e. You'd put all your "support functions" into other files other then the main programming logic (where you keep the meat of your program). This keeps your main program very clean -i.e. You don't have to worry yourself about the "unimportant (tried and true)" when reading/writing and maintaining your program. I wrote a utility to replicate this method for the lisp language. The utility is mostly in an "unmaintained" status now but I cannot imagine any new features that would ever need be added to it so it should be very useful as it is.

https://www.theswamp.org/index.php?topic=37700.0
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

Lee Mac

  • Seagull
  • Posts: 12726
  • London, England
Re: Questions for the experienced programmers
« Reply #6 on: September 30, 2016, 06:52:10 PM »