Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Phred (5358)


Fred is a Perl and PostgreSQL geek. He has made some very small contributions to a few cpan modules and mod_perl.

Journal of Phred (5358)

Friday June 27, 2008
04:17 PM

Code for yourself, or for your users?

[ #36799 ]

Allow me to make a generalization and ask a question at the same time. When you write your code, do you write it for yourself, or for someone who might use the code? Do you try to make your code as clever as possible, or as simple as possible?

At YAPC::NA 2008, Schwern had a great talk on skimmable code. Simple code frees up the programmer's cognitive resources to concentrate on the business logic, not on reading the code. One could argue "well, you're just not smart enough to understand my code". That's a valid answer, but it is more likely that I don't have the time to spend deciphering your code. I believe that I'm a reasonably intelligent person. But also a busy person, and it's rare enough that I get the time to write my own code and focus.

I'm starting to believe more and more that writing simple code is hard, and writing complex code is easy. Simple code is easy for your users to read, and it is easy for you to read as well. Most often, we are the biggest users of our own code. Damian had a nice anecdote in PBP about watching out for the person who has to look at your code six months after it has been touched. Most often, that user is you, so be kind to yourself and code for the inner user in you!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • "I have written you a long letter because I did not have time to write a short one."

    -- attributed [] to Blaise Pascal

    • Exactly. The quickest way to make a change tends to create "smart looking" code, but it makes it harder to make the next change because you end up with something like 4 elsif clauses where each one has 5 boolean statements and half of the booleans are negated. So, every change requires the programmer to decipher all of the conditionals and their constituent booleans, probably with zero comments.

      Grouping the conditions into a dispatch table would make it fairly self-documenting and allow room for comments

  • The first one is to try to code things in a straightforward way that anyone can understand. That means laying things out clearly, using a widely understood group of features, etc.

    The second one is that if I break the first rule, break it hard. If I really need to be really tricky, get all of the trickiness out of the way in one place. If I need to use an advanced feature like overloading, use it a lot so that anyone who has to work with the project will quickly be clued in that it is going on and how it

    • Is this what Einstein meant when he said:

      Make everything as simple as possible, but not simpler?

      How is it possible to make something simpler than is possible?

      • How is it possible to make something simpler than is possible?

        Everything is an object, in Java, even if you don't need it to be an object, in which case it's either a primitive (for efficiency), or namespaced global functions (a class full of static methods) -- but everything is an object in Java, because that makes everything easy.