Re: functions that take many arguments...... + extern - what about it?
- From: Martin Jørgensen <unoder.spam@xxxxxxxxxxxx>
- Date: Wed, 14 Jun 2006 12:11:21 +0200
Malcolm wrote:
"Martin Jørgensen" <unoder.spam@xxxxxxxxxxxx> wrote in message
Dann Corbit wrote:
"Martin Jørgensen" <unoder.spam@xxxxxxxxxxxx> wrote in message news:bp01m3-5g7.ln1@xxxxxxxxxxxxxx
-snip-
If you are passing 20 arguments, then you have a function that is incredibly difficult to debug.
Since 80% of the cost of software is maintenance, I think that is what should really curtail how much stuff we pass into our functions. By making the functions as small and simple as possible, we make them much easier to debug and hence to maintain.
Inside the function, it then calls other functions so the problem is split up into smaller pieces...
So if there is a natural hierarchy, express that in structures.
For example you have nx, ny, nz values, and then lists of doubles. It seems to me that this very easily falls into a group
typedef struct
{
double *x;
double *y;
double *z;
int nx;
int ny;
int nz;
} COORDINATESET;
Yes, good idea... That would get rid of a lot...
I am slightly puzzled that nx, ny and nz are different. So put a comment in the structure definition explaining why this needs to be so.
Ok, it's basically just nx = number of cells in the x-direction. double *x then holds the distances between each element... So inside the function: for(i=0; i<nx< i++) etc...
Similarly the show_ members are probably booleans. It is not usual to pass these as flags
#define SHOW_PLOCATONS 1
#define SHOW_RHOCP 2
#define SHOW_BOUNDARY 4
#define SHOW_NOTHING 0
That makes the call more humanly-readable, and you only need one parameter.
I can't do that, because those values are read from an input file (input.txt).
There are times when the complexity of the problem requires lots of parameters to our function. In such cases, we will have to rely on probabilistic testing + code coverage + endpoint (fencepost) style tests.
How is that done?
Code coverage means that you write your tests so that every line of code is executed at least once. So if you have an exit(0) after a malloc() call, you artificially manipluate the malloc() to fail at least once at that point. You can get automatic tools that will help you do this.
So the program terminates before it's supposed to do?
Most errors come when data is at the extremes of the range the code is expected to handle. So for instance if a function takes a string, it is a good test to pass it an empty string. If it is specified that the string can be 256 bytes long, pass it one exactly 256 bytes long and see whether allowance has been made for the null. This applies particularly to loops. Are the first and the last items in the list processed correctly?
Ok.
Probabilistic testing means that we haven't shown the program to be absolutely correct, but we have given enough test cases to make it a reasonable bet that the program is in fact accurate. It is very difficult to detect if a function chokes on the input telephoneno = "666". However why should it? If "666" is hardcoded into the function we should pick it up on a coverage test. But there just might be some gremlin in there, if it happens to hash to zero and we have forgotten that zero is a valid slot in the table, for instance. Even this should have been picked up by an endpoint test, but you can't expect to get everything right with limited time and budget.
Agreed... Sounds like my program... I have made a lot of tests, but I don't really know if there is some "666"-situation, where it gives a wrong result...
Best regards
Martin Jørgensen
--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk
.
- References:
- functions that take many arguments...... + extern - what about it?
- From: Martin Jørgensen
- Re: functions that take many arguments...... + extern - what about it?
- From: Dann Corbit
- Re: functions that take many arguments...... + extern - what about it?
- From: Martin Jørgensen
- Re: functions that take many arguments...... + extern - what about it?
- From: Malcolm
- functions that take many arguments...... + extern - what about it?
- Prev by Date: Re: Question about the *= (and similar) operator
- Next by Date: Re: Question about the *= (and similar) operator
- Previous by thread: Re: functions that take many arguments...... + extern - what about it?
- Next by thread: Re: functions that take many arguments...... + extern - what about it?
- Index(es):
Relevant Pages
|