A student sent me email to ask: “In a general sense, when writing code, is there a sequence of steps or a pattern to the logic when writing the code?”
It’s a good question. Experienced computer programmers have learned these steps-either through intuition or experience-but beginning programmers are often mystified. Once you learn the language syntax, how exactly do you use it to approach a programming problem? Especially if you want to try to use good programming techniques and to solve the problem in a smart and efficient way.
The answer to the question “Are there steps to writing code?” is “Yes”. After the jump, I’ll give three ways to develop the logic necessary to write good code.
Outline
When I have a complex bit of code to write, I start by writing comments to outline what I want the code to do. For example, imagine I’m adding an item to a shopping cart:
# get the ID of the item
# find the item in the database
# check if the item was found or not
# if not, then give an error
# if so, make sure there is enough inventory
#…and so on…
Once you have an outline to work from, then you can go back and write code below each comment. It allows you to get your thoughts organized-to say “Okay, what are we trying to do here?” Breaking a large problem down into smaller parts will make it less overwhelming and let you tackle once piece at a time. Outlining is also a good way to make sure that you don’t skip a step once your head is wrapped up in the code details. And, as a bonus, you’re code will already have some comments in place so you and other developers will understand the thought process.
Design Patterns
Design patterns describe the high-level concepts or abstractions that are frequently used in software. (Wikipedia: Design Patterns) There’s no sense in reinventing the wheel each time. Design patterns will not tell you how to write your code, but rather they provide a conceptual structure that can help to guide you and inform your coding choices. Design patterns is not a beginner subject (many of them will go right over your head), but even beginners can start to make use of them. My advice is to digest what you can, don’t worry about the rest and revisit them again each year. Wikipedia has some good information, but the best book to learn about design patterns is Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
Refactoring
First make it work, then make it work better without breaking it. In the simplest sense, that is what refactoring is. However, like design patterns, it is possible to describe those code improvements in high-level, abstract terms. (Wikipedia: Refactoring) You can look for “refactoring patterns” or places where a common refactoring technique can be employed to make your code clearer, faster, reusable, and overall more maintainable. The best resource to learn more about refactoring is the book Refactoring: Improving the Design of Existing Code by Martin Fowler. Refactoring techniques make use of design patterns so it’s worth exploring both. Also, since the goal of refactoring is to improve code without changing the results, code testing (such as unit testing and functional testing) becomes an important skill to develop to get reliable results from refactoring.
In my own work, I use all three. I try to recognize the design patterns I’ll need before I start. Next I outline before I code. Then I just try to make it work, writing very sloppy code I would never want anyone to see. Finally, I try to make it work better by looking for refactoring opportunities. (And often it isn’t so much looking for fancy refactoring patterns, but just for bone-headed choices and shortcuts that I made while getting it to work.) As I gain more experience, problems that once required me to employ all three techniques now get solved with pretty decent code from the start; and I can use those same techniques to solve harder problems. It is a bit like when you first learned to add and subtract using your fingers but then learned how to do those calculations in your head.
If you are an experienced programmer with additional advice for beginners on the steps to write good code, feel free to offer it in the comments.
Recent Comments