Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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?

share|improve this question

marked as duplicate by Kilian Foth, Jalayn, Martijn Pieters, Dynamic, Robert Harvey Jun 17 '13 at 19:04

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
It is difficult to know without actually seeing the class in question. In general you're correct - but then, adding lots of functions may add unnecessary overhead. Also what is structural programming? Structured? –  Dave Hillier Jun 17 '13 at 16:03
1  
So his argument is that you should stuff a 30+ case switch statement and all the logic that supports each case into a single 500 - 2000+ line function? Good luck picking out the case statements. –  Dan Pichelman Jun 17 '13 at 16:04
1  
I assume he means Structured Programming. –  Jörg W Mittag Jun 17 '13 at 16:05
2  
Besides the question mentioned by @KilianFoth please consider the answers to this two questions: Is it OK to split long functions and methods into smaller ones even though they won't be called by anything else? and Should I extract specific functionality into a function and why?. –  Trylks Jun 17 '13 at 17:15
add comment

4 Answers

up vote 17 down vote accepted

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.

share|improve this answer
2  
+1 for "organizing them so that code tells a coherent story". This is the idea that I'm trying to embrace. –  hydroparadise Jun 17 '13 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 '13 at 17:29
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
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 '13 at 16:14
2  
@DanPichelman Yeah, the reviewer is expecting to retire within the decade.... –  hydroparadise Jun 17 '13 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 '13 at 17:05
add comment

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

share|improve this answer
add comment

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