Using Routines in Programming

The longer I code the more I've learned that the key to good programming is in how you approach writing routines. Steve McConnell at http://stevemcconnell.com/ieeesoftware/bp16.htm lists the following 8 reasons and I provide commentary.

• Reducing complexity - I like to keep my routines short enough so I can read the routine declaration line to the bottom "}" all within one Visual Studio window. That's usually about 40 lines.


• Avoiding duplicate code - I agree its the most popular reason for routines.


• Limiting effects of changes - Doing the repeatable job in one place is important and that's why good requirements analysis and good software design/architecture up-front is essential in creating good coding practices.


• Hiding sequences - This is why good routine-writing is essential to good object-oriented programming as its through hiding sequences in routines that we accomplish good encapsulation.


• Improving performance - without good, organized routines you will never figure out where the bad-performing code is located


• Hiding data structures and global data - good for encapsulating, sometimes bad for documenting the data structures' usage so that future DBA's and architects can read the code and make future changes or integrated systems.


• Promoting code reuse and planning for a family of programs - This is where object-oriented programming provides real value with routines. And with the [obsolete] tag in C# and other code management tags & comment sections for .NET routines it makes it much easier to plan, document and validate code reuse or lack-of-reuse.


• Improving readability - well-naming and keeping the size of the routine down to 20-40 lines is vital. Making routines too short or not designing the high-level algorithm well will cause what I call "sub of sub of sub of sub of sub ... I'm lost and can't find the code" syndrome. Basically its not easy to have too many nested levels of subroutines to dig through in order to find the code you need to work with and this is a common problem I run across when the subroutines are too short and the algorithm was either not well thought-out or its undergone considerable change.


• Improving portability and isolating use of nonstandard language functions - interfaces and gateways from C# into COM libraries, external web services, external "C" code, etc. are well-managed through good routine writing.


• Isolating complex operations - this is one of the greatest use of routines - any complex task must be done through ONE routine with calls to multiple subroutines in cases where alot of code is needed