I got into a conversation recently coming out of the Houston.pm user group meeting. As usual, we wandered over numerous technical topics, but one stuck out in my mind: whether or not to use more advanced or more complicated language idioms. I’ve written about programming idioms and advanced code many times in the past (see… Read More »
As you probably know, code is read more often than it is written. Anybody who has worked on code written by anyone else has probably wished that the code were more readable at some point. Writing readable code should definitely be considered a best practice. The problem comes when defining what you mean by readable.… Read More »
One of the design ideas that came out of the early days of the agile movement was YAGNI. As I have written before, this idea is push back against the tendency of many programmers to over-engineer or over-complicate our designs. We normally use some variation of the flexibility argument to justify this tendency. In fact,… Read More »
As a first post in the Best Practices Gone Bad series, I figured I would take an simple example from a previous job. An Example In that position, there were two best practices that intersected to generate unreadable code. The first practice was expressive names. All names of variables, classes, and methods were required to… Read More »
Code Reading Diomidis Spinellis Addison-Wesley, 2003 I have had this book on my list of books to read for some time. Although I have been reading code for years, everything I had heard about this book suggested that it would help improve my reading skills. Unfortunately, halfway through the book I was mostly disappointed. This… Read More »
Randal Schwartz’s Perls of Wisdom Randal L. Schwartz Apress, 2005 Randal Schwartz has been writing about Perl since the first edition of the Camel Book. This book collects articles that he has written for a number of magazines into one place, organized (loosely) by topic. These articles span almost a decade of writing on the… Read More »
I just recently read Valueless Software, written by Chad Fowler from about a year ago. In this article, he describes an approach to practicing music by ignoring the result and focusing on the process. He contends that software people might benefit from a similar approach. I have actually seen this approach used before in C… Read More »
Reading Dave Thomas’s blog on Code Kata pointed to PragDave: MoreKata. I also stumbled across How To Practice on Chad Fowler’s blog. Both of these entries discuss exercises that we can use to master the art of programming. Perhaps surprisingly, they use metaphors and concepts from martial arts and Zen. Those of us who have… Read More »