> My challenge to everyone on the list is to start with any version of > the snake code you've seen and make it as readable as *you* think it > should be by doing things like renaming variables and functions, > adding comments and changing indentation. I'd really like to see what > *you* think is the best way to write this code. The lessons learned > from this exercise could then be applied to other code we write in the > future.
I'll keep this as short. Thanks to the folks who contributed to the snake code. I spent a few hours reading it, referring repeatedly to the API documentation, renaming a few of the variables, experimenting with snippets in REPL, and adding comments to the code so I wouldn't forget what I'd learned. I'm not sure that's a problem, though. I learned more in that process than I would have if the code had been excruciatingly documented. The level of "educational documentation" varies with the level of experience. Too much documentation in an example is just as bad as too little. I also wonder whether insisting upon coding standards might deter people from participating in this forum. Bill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
