High-Quality Routines

[[deleted user]]

Nice chapter, although I think that it should have come before the discussion of ADTs, classes, and other OO concepts. I like the technique of showing bad code (anti-code?) and how to improve it. I am glad to see the negative view of macros, so I feel less guilty about never naturally thinking about using them. The 7+/-2 advice for many code metrics is consistent with advice in other places, but I don't recall seeing the short term memory motivation before, which makes sense to me. I am not sure I agree with the benefits of the stringent parameter ordering of input, modify, and output, but I might be persuaded. Does anyone else routinely use a convention like this? Finally, as usual, good routine (and other) names are hard to find, but usually worth the effort.

[Erik]

"Avoid meaningless or wishy-washy verbs" - I'm guilty of this. My quick & dirty code usually has functions like DoStuff( ).

"Make names of routines as long as necessary" - I am guilty of this too. My coworkers often laugh at my function names. When I go back to work on bugs, it's always easy to remember what the function does based on a highly descriptive name. Some examples:
EL_ScanCurrentPageForPageWithGivenRecord( )
EL_ScanCurrentPageForPageWithThisIndexKey( )
EL_ProcessPageForPageWithThisIndexKey( )


I liked the C++ MACRO section. I use C++ alot, but I don't use macros very often at all. I agree they can be dangerous and cause debugging to be more challenging.

I do usually try to follow parameter ordering and/or grouping. I think it's nice when reading code. It's maybe just habbit now too.

[Aleksander]

I like routines. I like writing routings. And I like a magic behind routines declarations implemented by others, especially if using such routines feels like a “real magic”. Those routines require minimum work from users (they don’t require too many parameters or research), operate quietly and always correctly, and if requested can provide user with status of operation. I think this chapter provides enough information for me to start designing better routines that would be easier to read and maintain by other developers.