One thing that sometimes helps is to get the code on your screen, and read through it, word-by-word and punctuation-by-punctuation, pointing with your finger or mouse pointer, and "explaining" to yourself what each is actually saying, and check what it's saying against what you think it's supposed to say.

A slight variation on that is to step through the code like above, but explain what it's *supposed* to do, and then check against what the code actually says.

This is useful whether you are familiar or unfamiliar with the particular language/library you're using.

If it helps you be methodical, force yourself to explain it as if you are explaining to another person, rather than to yourself: https://en.wikipedia.org/wiki/Rubber_duck_debugging

Also, as you're reading through the code, when you're not very familiar with some of language or some library you're using, it sometimes helps to look up what the documentation says.  For example, if you're stuck on this bit of code, you might go look up in the documentation a `define` form means, what a lambda form means, a `cond` form, a `list? procedure application, etc.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to