Skip to content
Posts
A few days ago I posted about mitigating complex code issues and introduced my opinion that commenting should be viewed as a last resort.That post kicked up some discussion on Facebook with some of my friends:“Documentation and commenting is still important”-Close friend from college“I think it can be important, but I would much rather see time invested in writing better code and hiring more talented developers."-Former co-worker in response to above commentOf course I never meant to imply that code commenting isn’t important.
Lately I’ve been thinking about my current general philosophy on how to approach the code I work on each day. . .When I’ve solved a hard problem (or have a design for a solution in mind), I ask myself the following questions:1) Would a slightly more junior developer understand the code I just wrote? . . .See the genius behind the design I just implemented? . . .Understand why I wrote it the way I did?
Below is some code I wrote a while ago for an application that had been written in Perl.I was in a situation where I had to track dependencies on user actions. As an example:This action. . .Can NOT be completed before these actionsaction_4action_1, action_2, action_3action_3action_2action_2action_1But of course I wanted to give the user the power to specify any action they wanted. (including a list of actions) So, if the code was told to do ‘action_4’, it would look that action up, see that actions 1, 2, and 3 needed to be completed first, and then do them.