Cleaning Up Code - Question

[Snaef98]

Back when I first started my project I didn't understand the use of functions very well so I put the bulk of my game content that is the map and text portion of it within a single function.... now my combat routines, character and inventory display, quest log, experience calculator, quest updater, quest manager and all my other routines are in thier own functions, my question is

For stuff that requires alot of jumping around from area to area, that sometimes requires special positioning within that part of code i use some goto's depending on the situation. I also use alot of switch statements as its a choose your own adventure style game. My question would be, would it be wise to move each area to its own function.... for example

Area + Mapp coords like Area000 = Map [0,0,0] and put all the menu and text portion within that function and when a player wants to move to another location call up the corresponding function? Or would that be too much function calls?



I really do wanna organize the Game() function as putting 100s or 1000s of areas in 1 function is going to be a nightmare xD

[Snaef98]

Disregard i made a duplicate of my program and cleaned up my code. its just perfect!

[Fresh Grass]

I have similar question as well. What's better, more code or more conditions, functions, etc instead?
More code means bigger program, more conditions/functions means more things for program to do (checking, copying/referencing variables). At least that's my understanding.
Is writing more code going to make a program run faster or not? Is it really much more efficient to write shorter code and let the program do all the checks?

EDIT: Now that I really think about it, more functions usually results in fewer conditional statements than if we'd use no functions at all. I still want to hear an explanation from someone more experienced.

[Disch]

What's better, more code or more conditions, functions, etc instead?

ummm ... conditions/functions/etc are code. You're basically asking "what's better, more code or more code?"

Is it really much more efficient to write shorter code and let the program do all the checks?

The program only does what your code tells it to do. It doesn't "do all the checks" unless you put that in your code. What you're asking really makes no sense.

[chrisname]

These questions don't really make sense. What are you referring to as "code" and what are you referring to as "conditions and functions"? I'll try and answer anyway.

Fresh Grass wrote:

What's better, more code or more conditions, functions, etc instead

Well, more functions would generally imply more code. Unless you mean to split your functions into multiple separate functions, which is usually a good idea. Functions should be able to fit on a screen (the ANSI screen size being 80 columns by 24 rows), should do one thing, and should do it well.

Fresh Grass wrote:

More code means bigger program, more conditions/functions means more things for program to do (checking, copying/referencing variables)

If there is more code, then the program is doing more things. In any block of code, the amount of "things to do" is directly proportional to the amount of instructions once the code has been compiled, and the number of instructions required to perform some operation is usually inversely proportional to the speed of the operation.

Fresh Grass wrote:

Is writing more code going to make a program run faster or not?

Probably not. Given some operation, doing it in a small amount of code is most probably faster than doing it with a large amount of code.

Fresh Grass wrote:

Is it really much more efficient to write shorter code and let the program do all the checks?

This question doesn't make sense, so I can't answer it.

[Fresh Grass]

I'm sorry, I realize now that the question was very unclear. Bad example, but consider this:

for (int i = 0; i < 100; ++i) cout << "output";

or

cout << "output";
cout << "output";
cout << "output";
//etc.. 

First code will check a condition 100-times and don't forget about allocating a memory for the variable and incrementing the variable 100-times. Second code will give you a headache, but the program won't have to spent time doing all the extra stuff.
And this is a really bad example, but I hope you know a little bit better what I mean.

EDIT: Maybe a better example... Let's say you have a window form with multiple buttons. All button clicks do almost the same action. An example: Button A does a mix of X1 and X2, button B does a mix of X1 and X3, button C does a mix of X2 and X3.

You can send all button clicks to the same function but with a different argument value and write a lot of conditional statements in the function. The code will be short because you can group various button clicks into same blocks of conditional statements and it will be quick to write. X1, X2, X3, X4 etc - all in the same function.

or

You can write a separate function for each button click, even though they do almost the same thing. BUT, the program won't have to check which button was clicked. Function for button A will contain action X1-X2, function for button B X1-X3 and so on...
The obvious answer would be to put all actions (X1, X2, X3, X4, etc) in their own function. But I'm talking about a "mix" of actions. So the only thing left to do (if you want to separate the actions for each button) is to write a separate function for each button, thus repeating almost the same code over and over again.

I'm hoping for an "compilers optimize your code enough so that it doesn't really matter much" answer, because sometimes it's easier to write a lot of conditionals and sometimes it's easier to separate everything.

[chrisname]

In your first example, you unroll the loop. Loop unrollling generally leads to faster code, but it's really ugly. So you can just ask the compiler to do it; for gcc/g++ add "-funroll-loops" to the command-line.

[Fresh Grass]

That's what I wanted to hear. But I still want more general answer, not about specific statements.

For better understanding, the last example in pseudo code:

void onButtonClick(object sender) {
if (sender.name == "button1" || sender.name == "button2") do.action1();
if (sender.name == "button1" || sender.name == "button3") do.action2();
if (sender.name == "button1" || sender.name == "button4") do.action3();
if (sender.name == "button2" || sender.name == "button3") do.action4();
if (sender.name == "button2" || sender.name == "button4") do.action5();
if (sender.name == "button3" || sender.name == "button4") do.action6();
}

or

void onButton1Click() {
do.action1();
do.action2();
do.action3();
}

void onButton2Click() {
do.action1();
do.action4();
do.action5();
}

void onButton3Click() {
do.action2();
do.action4();
do.action6();
}

void onButton4Click() {
do.action3();
do.action5();
do.action6();
}

Now imagine something much more complex than this. What's better? I'm programming for two months, still in high school, so I haven't heard any lectures about algorithm-planning. That's why I'm asking.

[chrisname]

I would do it the second way, something like this:

typedef void(* button_click_t)();

button_click_t button_handlers[4];

/* ... */

/*
 * Button was clicked, call the appropriate function
 */
button_handlers[i]();

It's called a jump/branch table: http://en.wikipedia.org/wiki/Branch_table

[Snaef98]

Lol this wasn't exactly what my subject was about but feel free to have ur discussion since my problem is fixed, i was asking if seperating each area of my game into its own Area function was better then having it as one run on function with gotos, im still using gotos for switch statement default and certain goto menu when the user selects something that outputs text and resends him to the menu again, but at some point i want to implement an input integrity check as well which will further reduce the need for goto statements. right now with area functions my code is so much neater the sections are smaller and the benefit of using functions is you can use -+ to close that section of text so you can focus on just one function at a time when editing. it saves a ton of hassle down the road.