C++ Design: Too Many Arguments!!

Alice Sezzlehed - Sat, 12 May 2018 13:28:25 EST ooXJl0td No.37530

File: 1526146105683.jpg -(970836B / 948.08KB, 3048x2432) Thumbnail displayed, click image for full size.

Hi guys and gals,
My C++ program (a roguelike game with lots of lists) is becoming pretty large. As I try to clean things up, I’m noticing I’m creating huge ass functions with many arguments (since I’m passing so much data sets around).

I think I’m pretty meticulous about keeping track of everything, so it’s not that I’m running out of computer memory, it’s just the code is impossibly long and ugly. Is it normal to have functions with 10+ pointers to different datasets, etc.?? Or am I dokng somethig wrong - any idea how to fix it?

Id love to hear your ideas!!

Shit Fivingditch - Sat, 12 May 2018 16:03:00 EST Xm/W+3lL No.37531 Reply

My personal philosophy on programming is that after you get past the hump of learning how to do it, that there's no right or wrong way to do it (so long as your program actually works).

If you're interested in refactoring your code to be less long, consider refactoring some of these datasets that are commonly used together into classes or structs and then passing in the combined classes or structs instead of passing individual pointers to each.

Alternatively, what you could do is refactor a bunch of these commonly used lists and datasets into a big class, and then call functions on it. That way, you won't have to pass in any arguments, since a bunch of those elements would already be contained within the implicit "this pointer" of the code that you're running on the class.

>>	Shit Cigglehidge - Sat, 12 May 2018 18:17:47 EST DAnKBV7r No.37532 Reply Some functions will naturally have dozens of parameters and with defaults they aren't even unweildy. As previously said though, it sounds like you should make some structs or classes.

>>	Lydia Gudgedale - Sat, 12 May 2018 20:11:11 EST r5si74OP No.37534 Reply just make it work, throw it into valgrind, see where its actually slow, and then.. go from there... idk ive never done it, Ive only got a useless CS degree.. fuckin hire me.

>>	Isabella Gimmerhall - Sat, 12 May 2018 22:01:23 EST Xm/W+3lL No.37535 Reply >>37534 Question: If you've never done what you suggested before, but you have a CS degree, then what have you done?

Thomas Nucklekatch - Sun, 13 May 2018 10:54:24 EST 8hwK1pxu No.37538 Reply

>>37530
If I were you I would look into unit testing.

The idea is that each function you write should be one testable unit of work. And if you can't write a unit test for a function, then it might be a bad function.

One thing I see in code sometimes is someone will write a function A which does some stuff then calls B, which does some stuff then calls C, which calls D, which calls E, which calls F, and so on. But this defeats the purpose of functions and just makes your code harder to read.

>>	Isabella Gimmerhall - Sun, 13 May 2018 16:36:30 EST Xm/W+3lL No.37539 Reply OP, perhaps it would help if you posted your function declaration/definition here and we could provide more direct suggestions?

Fucking Sidgedin - Mon, 14 May 2018 02:00:31 EST naT3gKNs No.37540 Reply

>>37530
Note that in this answer, I'm assuming you're some kind of a beginner. Also, what you're probably asking for is help on writing a "state machine" which I'm certainly not an expert in. What follows is general advice on function design. And sorry for the wall of text...

Imagine the following: tomorrow you're going on a trip for 1 year and you don't take your project with you. After you come back, will you still be able to read/understand your thing?
So the question probably becomes: "What can I do to make my code easily navigatable, understandable, and workable?"
And I have to tell you that some things are probably just experience. Here are some tips though:

Comment your code well. This doesn't mean lots of comments, it means commenting anything that is not obvious. Note that things like variable/function names are also comments in a sense, so use those to your advantage (e.g. trying to encode the type of a var inside its name is mostly useless. Rather, you could name a var after its intent.). Above every function goes a comment that at least describes what goes/can go in it and what can come/comes out of it and roughly what it does; probably also useful for things like structs/data types.
Group things together that belong together. This can mean to make use of stuff like structs (or sth similar, depending on language) but also to e.g. have functions only do a specific thing that "belongs to its territory" rather than do things that have nothing to do with it. If you have the impression that a function shouldn't be doing a specific thing which is still necessary to do at this point, you should probably split that part off into a new function.

I guess what I really want to say is that you should't necessarily look (or even worry) at things like "line count in a function" or "number of parameters" -- such metrics don't often say much about actual maintainability (or performance) of code. Make your code understandable: a function should follow a single train of thought and you should be able to follow a function in a single train of thought. And sometimes (though admittedly rarely) that can mean having a big ass function somewhere.

>>	Jarvis Bemmerbury - Mon, 14 May 2018 19:00:49 EST r5si74OP No.37541 Reply >>37535 Oh it would be so cool if the outdated university curriculum included stuff like that in it.

Doris Cradgelot - Fri, 18 May 2018 04:12:24 EST +joVuqaF No.37544 Reply

If you're using a lot of default values you can initialize them with a lambda (an anonymous function) like:

int foo( int n ) {
auto bar = [](int n, int constant) { return n + constant; };
return bar( n, 2 );
}

This is an extremely contrived example of the partial application pattern, but the important thing to note is that the `foo` function only takes one argument, then `bar` is called from inside with both the default argument and the argument passed to `foo`.

>>	Esther Pullerforth - Mon, 21 May 2018 02:44:25 EST Xm/W+3lL No.37545 Reply >>37544 I personally find lambda function usage in C++ more complicated than standard explicit named function usage most of the time.

Hedda Turveywater - Mon, 21 May 2018 15:20:05 EST +joVuqaF No.37546 Reply

>>37545
The lambda expression comes in handy for partial application because you can't nest standard functions in C++. Plus, if the lambda is only meant to be a helper for one particular function, you wouldn't want it to pollute the global name space anyway.

Phyllis Dunnerbudging - Wed, 23 May 2018 11:09:54 EST De9RwqWL No.37547 Reply

>>37530
Yes, roguelike games have many pointers to different datasets like: character attributes, monsters, spells, potions, locations.
And the routines can be very very long, especially the case statements covering all possibilities.

In contrast to what others say, generally do not split routines into smaller functions if there is only one caller. Otherwise you will be scrolling all over the place and making a bigger out-of-context mess than you can imagine.

What you should do is avoid global variables. Collect them all into a larger struct and pass that along as a pointer to a 'global dataset'.

Look into nethack and ularn for comparison.

Name	You can leave this blank to post anonymously, or you can create a Tripcode by using the format Name#Password

Comment	[i]Italic Text[/i] [b]Bold Text[/b] [spoiler]Spoiler Text[/spoiler] >Highlight/Quote Text [pre]Preformatted & Monospace Text[/pre] [super]^{Superset Text}[/super] [sub]_{Subset Text}[/sub] 1. Numbered lists become ordered lists * Bulleted lists become unordered lists


File	No Bump Sandwich

Report Post
Reason
Note