Is it good to have many functions in one file?

Started by
7 comments, last by Zahlman 16 years, 2 months ago
I'm making a game and I have different files that do different tasks. For example, graphics initializes the graphics and also does some tasks that have to do with graphics, like applying an image or drawing a square. In the main function, I have a vector that holds the objects are to be drawn. Then I call the function and draw them.

void drawFruits( const std::vector <Fruit>& fruits )
{
     if( fruits.size() > 0 )
    {
        for( std::vector <Fruit>::const_iterator iter = fruits.begin(); iter < fruits.end(); ++iter )
             applySurface( iter->x, iter->y, iter->ReturnImage(), screen );
    }
}

The above code is in main.cpp, where int main is. If I had the same function in graphics.cpp, it would need one more parameter, which is the surface that I want to draw on, since I pass to a different file. It would look like this:

void drawFruits( const std::vector <Fruit>& fruits, const SDL_Surface* const screen )
{
/*blah blah blah*/
}

The question is, which is better to be used?
Advertisement
It really makes no difference in such a context. I personally like the first because I takes only one argument.
[size="2"]I like the Walrus best.
first off fruit is the plural of fruit not fruits. It is best to keep functions logically grouped. I would put it in the graphics file as it is graphics related.
SDL stores the video surface internally, and provides a function to access it: SDL_GetVideoSurface():
void drawFruits( const std::vector <Fruit>& fruits ){    SDL_Surface *screen = SDL_GetVideoSurface();     for( std::vector <Fruit>::const_iterator iter = fruits.begin(); iter < fruits.end(); ++iter )            applySurface( iter->x, iter->y, iter->ReturnImage(), screen );}


Note: don't check if fruits.size() > 0, check if !fruits.empty(). However, because a for loop will check the condition before the first loop body iteration executes, the check is redundant.
It depends on how you separate your functionality into logical groups. If the "Graphics" group is intended to be limited specifically to dealing with platform and API-related graphic duties, then the function "DrawFruit(s)" sounds awfully game-specific to be located within the "Graphics" group.

If, on the other hand, "Graphics" is intended to hold all things related to drawing, even the game-specific bits, then it would fall logically into that category.

That said, it would be my opinion that the former approach is more sound than the latter from a software-engineering and design perspective, and I would suspect that finding an experienced coder who disagrees with me on that point would be a difficult task. DrawFruits is better categorized as game or presentation-specific functionality, and should be located accordingly.

throw table_exception("(? ???)? ? ???");

Quote:Original post by rip-off
SDL stores the video surface internally, and provides a function to access it: SDL_GetVideoSurface():
*** Snip ***

I can't believe that all the times I've used SDL I've neglected that feature and just passed an argument...That could've saved me tons of time!

I usually tend to put functions in quite a few different files for two reasons: readability and re-usability. It is much easier to recycle code that works "independent" of the situation at hand. For example, to re-use the code in the same file as your main() function you would have to paste it into a project with the exact same conditions because it relies on certain things defined in that file. It would be much easier to just be able to include it by "#including" a separate file, knowing that it finds out everything it needs to know (such as the surface) by itself. Hopefully that's clear. Also, once you get too many functions in one file it becomes fairly hard to locate them to change them.

That said, I guess it really all comes down to personal preference, so do whatever you like.
Quote:Original post by bschneid

I can't believe that all the times I've used SDL I've neglected that feature and just passed an argument...That could've saved me tons of time!



Well, if you're like me and you've been trained to use OOP methodology, you're probably put-off by the idea of accessing some resource via a globally accessible function. There's just something "dirty" about it. [smile]

Quote:Original post by rip-off
SDL stores the video surface internally, and provides a function to access it: SDL_GetVideoSurface():


Wow I didn't know that, thanks a lot. Now I don't have the problem of passing two arguments instead of one. :)
Passing the argument gives you flexibility (e.g. the ability to render onto an off-screen buffer), at the expense of convenience. This is a common trade-off in software engineering.

This topic is closed to new replies.

Advertisement