Skip to content
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.”
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_1
But 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.