2

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?

Improve this question
4

4 Answers 4

Reset to default
17

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.

Improve this answer
2
  • 2
    +1 for "organizing them so that code tells a coherent story". This is the idea that I'm trying to embrace.
    – Chad Harrison
    Jun 17, 2013 at 16:07
  • 2
    The human mind can hold a series of about 5 +/- 2 "steps" as a single unit. So, it often makes sense to have a procedure that calls 5 others, where the five steps are approximately at the same level of abstraction. It is not just about programming: even in natural language, we have paragraphs, section-headings, chapters.
    – Darius X.
    Jun 17, 2013 at 17:29
6

"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.

Improve this 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.

Improve this answer
1

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.

Improve this answer
3
  • 2
    A very long time ago the "cost" of calling a subroutine was sometimes nontrivial to the point that developers would avoid them unless necessary. I'd wager the reviewer is "of a certain age" :-)
    – Dan Pichelman
    Jun 17, 2013 at 16:14
  • 2
    @DanPichelman Yeah, the reviewer is expecting to retire within the decade....
    – Chad Harrison
    Jun 17, 2013 at 16:20
  • @DanPichelman while it is for a different reason these days there are still places where there is a noticeable cost either in performance or complexity. Heavy iteration in .net for example can be faster under the Linq variants (.foreach(x=> ...) rather than the old foreach(x in y) let alone PLinq) because of the reduction in overhead and better optimization and throwing subs in there can detract from that. From the tone of the question I doubt this is the case here, but the idea still exists for some modern uses.
    – Bill
    Jun 17, 2013 at 17:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.