Breaking up is hard to do

Started by
15 comments, last by antareus 19 years, 7 months ago
I think it's generally a good idea to break up the code into smaller functions that each only do one thing - as many as conceptually practical. This of course makes reading and trying to understand a particular function a lot easier later on. However, a side effect of this is that the source files almost become cluttered up with a plethora of small functions, and some of the general view is lost. This must be why some languages allow defining sub-functions, right? I have tried a few ways to accommodate for this, like using namespaces or more files. More often than not a particular function is only called by one other function, so I've been thinking if it makes sense to somehow indicate that (on the naming of the function or so.) And also name private methods with a special prefix like many programmers like to do with private data. What's you view on this and how do you usually work this out?
Advertisement
You can work around C++'s lack of sub-functions by defining a class inside of a function and then making static class member functions:

void Read(){ struct Impl {  static void DoReadInt()  {   // ...  } }; Impl::DoReadInt();}
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
Quote:Original post by antareus
You can work around C++'s lack of sub-functions by defining a class inside of a function and then making static class member functions:

*** Source Snippet Removed ***


Somehow, I don't think that's an improvement.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
I do. You can drastically reduce the scope of functions by using this technique and avoid cluttering up the outer class with the definitions. When combined with templates on the outer member function, it is very powerful. I can make overloads on the inner class's functions that call either CreateFileA or CreateFileW depending on the type of the string the user passed into the outer function (which is templated).

Nesting a class inside a function also makes it final. It is impossible to derive from outside of that function. Alas, inner classes cannot be templated.

I am curious to know why you do not think it is an improvement, however.
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
That's a very interesting approach. So you usually do this. It clearly isolates the sub-functions as you said.

But it feels a bit indirect, and that makes me wonder why C++ doesn't support sub-functions. Is it because they want to promote object-oriented design in contrast to the "older" top-down approach?
Are you only talking about languages that don't have the almighty lambda? Surely you are familiar with it. If not, then learn here.
Quote:In using sum as in section 1.3.1, it seems terribly awkward to have to define trivial procedures such as pi-term and pi-next just so we can use them as arguments to our higher-order procedure. Rather than define pi-next and pi-term, it would be more convenient to have a way to directly specify ``the procedure that returns its input incremented by 4'' and ``the procedure that returns the reciprocal of its input times its input plus 2.'' We can do this by introducing the special form lambda, which creates procedures.

Quote:Original post by antareus
I do. You can drastically reduce the scope of functions by using this technique and avoid cluttering up the outer class with the definitions. When combined with templates on the outer member function, it is very powerful. I can make overloads on the inner class's functions that call either CreateFileA or CreateFileW depending on the type of the string the user passed into the outer function (which is templated).

Nesting a class inside a function also makes it final. It is impossible to derive from outside of that function. Alas, inner classes cannot be templated.

I am curious to know why you do not think it is an improvement, however.
I agree that it can be an improvement but it isn't 'the done thing' and isn't a commonly published idiom so people reading your code will generally react as Promit has.
Quote:I agree that it can be an improvement but it isn't 'the done thing' and isn't a commonly published idiom so people reading your code will generally react as Promit has.

Tough. It is not rocket science, or even half as tricky as some template metaprogramming. I don't see why people would be averse to learning the ins and outs of the language.
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
Quote:Original post by antareus
Quote:I agree that it can be an improvement but it isn't 'the done thing' and isn't a commonly published idiom so people reading your code will generally react as Promit has.

Tough. It is not rocket science, or even half as tricky as some template metaprogramming. I don't see why people would be averse to learning the ins and outs of the language.
Part of maintaining code is recognizing what the original author intended. Seeing an idiom that isn't used commonly can throw people for a loop (requiring multiple readings to figure out the intention). Even if it is technically sound and concise, the politics or maintainence make this a suspect idiom.

It depends on who you expect to follow you in the role of reading your code. Do you have a lot of code monkeys where you work -needing the most basic languages (as newspapers write in English at a third grade reading level) or very expert people who will immediately know what you mean (as technical journals meant only for graduates in a specific field). There are benefits to writing to target either group.

Write for the target audience.

[Edited by - flangazor on September 15, 2004 7:15:06 PM]
Quote:Original post by flangazor
Write for the target audience.


The compiler! [pig]
Quote:Original post by antareus
I am curious to know why you do not think it is an improvement, however.


I was not familiar with the actual reasons for doing such a thing, so I found it to be unnecessarily complex. Your explanation certainly helps to describe why you'd do something like that...although I must admit I'm still a bit wary, as I've never had a need for anything of the sort myself. And you just gained 17 points.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

This topic is closed to new replies.

Advertisement