I've came back to reading "Code Complete" after a couple of months. IMHO, reading this book all-at-once is a) boring, b) not much stays in the head, therefore I read a chapter at a time, trying to think it over before I get to the next chapter.

Now I'm at chapter 16 - "Unusual control structures" and want to share my thoughts:

  • Quote: "Computer scientists are zealous in their beliefs, and when the discussion turns to gotos, they get out of their jousting poles, armor and maces, mount their horses, and charge through the gates of Camelot to the holy wars".
    LOLisimo... when books/articles speak about goto, some funny quotes are always expected. McConnell makes no exception.
  • In "The argument for gotos" the author mentions good usage in the sake of cleanup. When code allocates resources, and in many cases must clean-up (errors, for example). There, goto saves from code-duplication. I actually had experience (mainly in C) with such cases... my solutions around goto weren't pretty...
  • "Error processing with gotos" - When there are a lot of errors to process, and for each error cleanup code must be executed. What would you do ? One no-goto solutions is heaps of nested IFs - YUCK ! The solution with goto looks /much/ cleaner. I'm usually using the 3rd solution - status var. Some flag "error_found" is set and checked once in the end. No gotos, no ugly nested IFs.
  • "Recursion isn't useful very often" - ahh... that's just not true. Hours of joyful Lisp hacking prove otherwise. Recursion is very useful ! Many data structures and problems in general have a natural recursive solution.
  • "Don't use recursion for factorials and Fibonacci numbers" - the author is right here, with one reservation. He's right because factorial and fibonacci can be coded iteratively w/o much effort, and the implementation would be much more efficient than recursive. The reservation - Lisp compilers know how to turn recurson into tail-recursion that is reduced to iteration. Let the compiler do the work for you ! After all, factorial and fibonacci are inherently recursive processes. Their recursive implementations are much more elegant than the iterative ones.

One more thing about the last point: I wish efficiency wouldn't matter that much. Not that it matters now in most cases, but in some of the more important ones it does.

Recursion has a few notable advantages. When applied to recursive problems (graphs, trees, mazes, parsing, inheritance... et cetera), recursive solutions are very elegant and simple, while the iterative ones are cumbersome. Also, recursion encourages functional programming style, which Is Good (TM).