Is using subprocedures to logically separate my code a bad idea for structured programming? [duplicate]

Question

This question already has answers here:

One-line functions that are called only once (11 answers)

Closed 7 years ago.

Most of my programming experience is in OOP where I have fully embraced the concepts thereof including encapsulation. Now I'm back to structured programming where I have a tendency to logicaly seperate my code using subprocedures. For example, if I have a large switch case (30 cases or more), I'll put that in it's own procedure so the main method looks a little "neater". Generally, subprocedures are used to help keep things DRY, but in some instances these logical seperations I create usually amount to being used only once.

Some of my code was being reviewed, and it was mentioned that this is a bad idea. His backing to this claim is that it muddies the water and "unecessarily hides" code. Instead, he insists that a subprocedure MUST be used more than once to merit making a subprocedure out of a section of code. While this idea of "hiding code" is a common place in OOP, he does admit to having little to no understanding of OOP concepts and has only ever worked with structured programming.

Is there any backing to his claim or is this merely programming dogma?

Answer 1

Encapsulation, Data Hiding, Abstraction, Writing Readable Code etc. are nothing that is unique to OOP. In fact, all of those were invented long before OOP. Really, the only difference between OOP and other paradigms is the mechanism of Data Abstraction: OOP uses Procedural Abstraction, others typically use Abstract Data Types.

Breaking up Subroutines such that every statement (or top-level expression in the case of languages that don't have statements) is on the same level of abstraction and organizing them so that the code tells a coherent story, is a universal principle, completely unrelated to any particular paradigm.

Answer 2

"Unnecessarily hiding code" is sometimes called information hiding. It is much older than object-orientation, and in Code Complete (first edition) it was described as one of the most important improvements in programmer productivity in history.

Answer 3

It's a reasonably common maxim that a function (to use C terminology) should be no more than one or two screens worth of code (example), with the reasoning being that it's easier to take in the entirety of what the function does without having to repeatedly scroll up and down.

It's certainly the case that when a function runs into hundreds or even thousands of lines it becomes more difficult to read and understand. I think you need to be pointing this out to your reviewer.

Answer 4

I would say dogma, but to me that implies adherence to a separate standard, and while he may not be totally alone on this, I don't think there is a large body that agrees with him.

Sub-procedures shouldn't be a single command, but turning a 5 case switch statement with blocks of 10-20 lines, into 5 subroutines and a switch statement that is 5 lines long, is going to make the code more readable.