OK, so you are a hopeless case.
You post a thread bragging about how extensible and superior quality your code is. I give you a lengthy analyses. You disagree to everything and admit that your code indeed only works for this particular, very specific use case and there are no reusable parts for similar projects and that small changes cannot be made without major rewrites.
No you can just rename the file.
You mean, in Windows Explorer?
What if the moon was made of green cheese?
The vital data is what cannot be saved there is nothing you can do other than exit.
I would have thought that the more vital the data is, there more things you might want to try before you give up.
If I made a lengthy Word document and for some reason Word failed to save it, I wouldn't be happy if the program just chose to exit.
I only had one array to save so that what I did.
OK, but you haven't answered what you would do if your boss came to you and said there needs to be two arrays or if you simply changed your mind.
Being ready for such cases is all that extensibility is all about. I find it very practical to program with a little margin for extra requirements / requirement changes, and in this case I would simply add the other array and call the same functions with different arguments. As far as the file-routines are concerned, only a coulple of lines would be added. How many lines of code would you have to change?
Code:
It's a simple matter to modify the code for differnt hand size if required.
OK, you are countering all arguments that it is trivial for you.
Please post your updated routine if hand size is chosen arbitrarily by the user at run-time, perhaps even changed during program run. I might then post the same change (I didn't plan this change, because that would require using dynamic allocation over static).
Code:
There are numerous other modifications that could be specified, such as a certain two
cards must be in the straight, but to think of every condiseration before writing a piece
of code is a complete waste of time.
Of course you can't program having any potential and bizarre requirement change in mind.
But if you studied my example, you might find that for me that requirement would be easy to implement because my implementation already finds the cards that belong to the flush.
Why did I write it so, even if current requirements didn't demand it?
Because
a) the function produces this information naturally as a by-product without any extra cost,
b) it would have been stupid to throw away data that obviously could have versatile uses - for example for comparing two player's hands, if this function was to be reused in a multiplayer project.
You only need to give it the functinality it needs to work.
And that precisely means non-reusability and non-extensibility. Especially since you do it in a way that burns all bridges for reuse - hard-coding, globals, magic values etc, etc.
I don't mind if you program privately in any way you like, but if you start bragging about the quality of your code - seeing that you are almost unable to produce a single line of code without exhibiting some bad practice - you get what you deserve.
You act like somebody who has only managed to learn to crawl - trying to convince people that crawling is the superior method of movement.
Code:
datasave(var1,var3); would also give a problem because you are using the function incorrectly.
If that compiles in C, then you have just pinpointed another problem in your code. The proper signature should be
Code:
void datasave(void);
and the compiler would stop bad things from happening.
People use to think the world was flat.
Think about it.
There were people teaching that at the time.
Has it occurred to you that may-be it's you who is teaching that world is flat.
As to flatness of Earth, it was mostly a church dogma (at a time). People who knew had to keep silent while the vast majority was uneducated and just didn't care. (Just like non-programmers wouldn't have an opinion about global variables.)
The shape and even the size of the Earth was quite well known in the Antiquity, if I'm not mistaken.
Originally Posted by laserlight
You are right. Neo1 is wrong to say that all functions must return some value. Indeed, Neo1 gave a counterexample in the same post: functions with a return type of void do not return a value. On the other hand, Neo1 also pointed out that your functions are supposed to return a value since you did not specify that their return type was void. Since you do not intend them to return values, you should declare them with a return type of void.
