A while back, Ceiling Cat said on Twitter, 'I liek Linucks, liek goldun rool: "Codez fer othurs as yu wud codez fer yerself." Srsly.' I like the idea of "Coding for others as you would code for yourself.", but sometimes I think that coding for ourselves is the source of a lot of problems in computing. As a coder, I don't usually mind looking at the code to figure out how to use the program. For that matter, if I find a program that does something I find interesting, I'm likely to look at the code (if it's available) to see how it was done. If I'm writing a quick script to solve some problem I have right now and may never have again, I'm unlikely to write in a help function, but I'll probably put a comment in at the top saying how to use the program. If I write a utility for myself, I may find it simpler to change code than support command line options. If I write documentation, it will be as comments. I don't think any of these traits are unique to me as a coder, but I don't think they are common to the general public and when I write a program, it's not usually for other coders. It is for people who want or need to do whatever it is that my program does. Even when I'm writing for other coders, it's likely that the majority of the time they will just want my program to work, not explore my code. Think about what coding would be like if every time you wanted to use your compiler or interpreter, you had to read and/or change the source code and recompile. This isn't the experience I want for my tools, or even leisure software, like games.
More than coding for others like I would code for myself, I should code for others like I wish others would code for me. Mainly, that means code that "just works" – it should do what I expect and when it doesn't it should tell me what went wrong. That means providing meaningful error and help messages. That means that there is an easy way to make common behavioral changes and configurations, whether that is command line options and a config file for a Linux program or a configuration screen in a GUI or web-based program. That means that the program has been tested, that it does what it claims to, and if it fails it does so as gracefully as possibly. It means that it handles my information securely and respects my privacy. It means it doesn't cause a security vulnerability on my system (or if despite the authors best efforts, a security hole has snuck in, a fix is made available quickly.) It means that there is documentation appropriate to me as part of the user audience, whether that is a Unix man page, an illustrated manual, or a video tutorial.
I'm sure that all of you have your own additions and requirements that you would add to this list. Imagine what software would be like if we all wrote code like this. Of course, this isn't always realistic, you may have resource limits that keep you from being able to always produce to this quality and except for the smallest projects you probably do not have control over all of these deliverables. However, if we all aim for this standard in our work to the level that we have control over it, think about how much better software could be!
Ceiling Cat on Twitter(The cited quote)
Ceiling Cat Paper Model
LOLcat Bible Online and at Amazon
For more information on good coding standards, check out Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman