Function size...

L

lombrozo

Hi,

I'd like to ask all of you experienced, well-structured,
Object-Oriented programmers out there about function size.

I am using Visual C++ to create an application, everything is nicely
structured, plenty of classes and inheritence yadda yadda. That part
of my code I am happy with. However, I have this one worker thread
(single function) that I am worried about. It's 1400 lines long.
Now, I remember while at Uni being told that functions should be about
one page size maximum (say 60 to 70 lines), but I don't think this is
applicable for my thread function.

So, I am worried that this function is too long. But surely,
different functions must be different sizes because of the context
they are used, and the purpose they are fulfilling? My function is
quite simple, it sits in a while loop picking of elements from a
global array. It then checks the element for various conditions and
writes any error information to a log file. The elements of this
array are quite big, and contain quite a bit of data, so it takes
quite a lot of code to process the element.

Can anyone give me any advice? Is the function too big? I could
split it into many smaller functions, but what's the point? It would
still follow a procedural execution, only now we have the overhead of
function calls.

Any help would be much appreciated!

Thanks,

Simon.
 
V

Victor Bazarov

Agent Mulder said:
I have this one worker thread
(single function) that I am worried about. It's 1400 lines long.
So, I am worried that this function is too long.

1400 lines is quit long. [...]

:))).. I really like this typo. "If your function is 1400
lines, it's so long that you should quit". No, Agent, I am
certainly not laughing at you, I am laughing with you.

Victor
 
A

Agent Mulder

I have this one worker thread
(single function) that I am worried about. It's 1400 lines long.
So, I am worried that this function is too long.

1400 lines is quit long. You already tried to take out common
functionallity, I suppose. So if the 1400 lines are really
necessary, there is no need to split it up in, say, 28 functions
each 50 lines long. Leave it like it is and cherish it as 'the
big function'.

-X
 
J

John Dibling

Can anyone give me any advice? Is the function too big? I could
split it into many smaller functions, but what's the point? It would
still follow a procedural execution, only now we have the overhead of
function calls.

First of all, let me just start by saying that 1400 lines is probably
too big, simply for maintainability's sake. Imagine stepping through
1300 lines of code you know isn't causing a problem, just to get to
the 100 that are suspect.

That said, I don't place much stock anymore in the 1-page-long rule of
thumb. I have found that when a function is 'too long' and I try to
break it up, the resulting smaller functions are in aggregate much
more complex than the monolithic original was. This I find is
especially true when dealing with complex Windows GUI issues, such as
customized common controls. Often the case is that a function is 90
lines of boilerplate and initialization code, and 10 lines of real
work. If I try to split that code in to 2 functions, that's 180 lines
of biolerplate code, and the same 10 lines of real work.

I'm *not* saying that there is no point at which functions become too
long. I'm saying that it is silly to constrain yourself to 70 lines.
It seems completely arbitrary. Why is 70 lines ok, but 140 is not?

</dib>
John Dibling
Witty banter omitted for your protection
 
E

E. Robert Tisdale

Something said:
1400 lines is quit long.
You already tried to take out common functionality, I suppose.
So if the 1400 lines are really necessary,
there is no need to split it up in, say, 28 functions
each 50 lines long.
Leave it like it is and cherish it as 'the big function'.
 
A

Alexander Terekhov

lombrozo wrote:
[...]
Can anyone give me any advice? Is the function too big? I could
split it into many smaller functions, but what's the point?

There's no point. 10-20 pages of some trivial "dispatching" code (or
something like that) is OK.

regards,
alexander.
 
A

Alf P. Steinbach

lombrozo wrote:
[...]
Can anyone give me any advice? Is the function too big? I could
split it into many smaller functions, but what's the point?

There's no point. 10-20 pages of some trivial "dispatching" code (or
something like that) is OK.

You troll you!, Alexander. ;-)
 
T

Thore B. Karlsen

Hi,

I'd like to ask all of you experienced, well-structured,
Object-Oriented programmers out there about function size.

I am using Visual C++ to create an application, everything is nicely
structured, plenty of classes and inheritence yadda yadda. That part
of my code I am happy with. However, I have this one worker thread
(single function) that I am worried about. It's 1400 lines long.
Now, I remember while at Uni being told that functions should be about
one page size maximum (say 60 to 70 lines), but I don't think this is
applicable for my thread function.

I don't agree that there is a set minimum number of lines above which
you can never go, but 1400 lines is way too big. I highly doubt it truly
needs to be that long.
So, I am worried that this function is too long. But surely,
different functions must be different sizes because of the context
they are used, and the purpose they are fulfilling? My function is
quite simple, it sits in a while loop picking of elements from a
global array. It then checks the element for various conditions and
writes any error information to a log file. The elements of this
array are quite big, and contain quite a bit of data, so it takes
quite a lot of code to process the element.

Can anyone give me any advice? Is the function too big? I could
split it into many smaller functions, but what's the point? It would
still follow a procedural execution, only now we have the overhead of
function calls.

In my experience, it's not hard to break up very large functions into
smaller pieces. The end result is much more maintanable, expandable, and
robust. Oftentimes it also results in much _less_ code, especially when
a lot of error handling is involved.

I'd say definitely give it a good try. Refactoring isn't easy, but once
you try it you will see the benefits. I've worked on code where 1400
line functions seemed to be the norm (it sure felt like it), and after
trying to maintain such code I think such monolithic functions are
completely indefensible.

I really hope you're not doing any kind of manual resource management in
those 1400 lines...
 
M

Mickey Mouse

I would definitely break this down into separate functions. Add methods
like:

- updateDroppedFrames()
- updateVideoStandard()
- updateDigitalInput()

etc...


This will be MUCH more maintainable...
 
S

Samuel Barber

Can anyone give me any advice? Is the function too big? I could
split it into many smaller functions, but what's the point? It would
still follow a procedural execution, only now we have the overhead of
function calls.

Function call overhead is never a reason not to use multiple
functions. Any decent compiler will do inlining (should be automatic
for single-use functions; if not, you can use the "inline" keyword).

Sam
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top