The word "procedures" here is a bit of an anachronism I guess. Today we talk mostly of "methods " Perhaps we talk about "functions" or "subroutines" but we are really talking about the same things. We are talking about small routines with a defined way in and a defined way out. Generally we work pretty hard to make sure there is only one way in and one way out.
This is another proverb that has so become ingrained into the way we write code today that few even think about it. That's probably a good thing. Today we don't think about huge programs but about lots of small methods/functions/subroutines/procedures. These are the logical units that make up our solution.
One thing I would add to this thinking is that we need to teach more about refactoring. Beginners have this tendency to have code that grows over time. What starts out as a small, simple routine grows and grows in size and complexity. We need to teach beginners to recognize when something is too big and then how to create a new small procedure (or several) from the mess.
Refactoring tools that allow us to make this happen in an automated fashion have the potential to help avoid a lot of cut and paste errors. Some may argue that this is an advanced tool but I wonder if it is not even more important for beginners to learn. Experienced professionals working from a good design are less likely to need these tools unless the scope of a program changes unexpectedly. Well it's a theory anyway. Probably an unreasonable dream. But still teach them about this early. Maybe it will help get them into the "small is good" frame of mind early.
This is the sixth of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.
we need to teach more how to AVOID refactoring, something like THINK first :-)
Great article, and I agree 100%. But not only is the use of refactoring important for beginners, but it is also important for seasoned developers. In the real world, very few developers really due fully top-down design, meaning that all their classes are fully defined, including methods, parameters, names, etc., prior to starting coding. It is just not practical to either generate all that documentation ahead of time, or to keep it all straight in your head. Instead, most developers I know sketch out a general design (e.g., UML models), and then start coding bottom-up, starting with simple functionality, and then adding, adding, adding.
What refactoring gives is a flexibility to improve the names of things later - which in my opinion is very important - as well as to move functionality between methods, change method signatures, etc. I personally believe this is a real benefit in terms of writing good-quality maintainable code.
I believe those who are not sold on the value of refactoring probably haven't used it. And I also don't believe in that type of attitude that refactoring is the sign of a bad design, or not thinking things through ahead of time. The old saying goes that we can only keep 7 +/- 2 things in our mind at a given time, and this doesn't exactly map well to software systems that might have dozens or hundreds of classes, each of which will have dozens of methods. It can't all be thought out ahead of time.