Thread: esbo's data sharing example

That global variables hinder extensibility.

Oh, I see. Kindly provide a mathematical proof that global variables help extensibility.

Esbo:

A function must always return something, as Elysia already pointed out. In your functions, the correct type would be void, this is common knowledge to anyone who uses C, if a return-type is omitted, the default is integer, but then you would still have to atleast "return 0;" or something, anything else is just poor style and will be frowned upon by other programmers.

If you do not believe me you can refer to virtually any tutorial on C functions, this is stuff that i learnt during my first week of programming. So i guess that's gonna go in the change log for your un-improvable program eh?

Is it really so hard to understand that these functions are only useful

- if you have one and only one array that you wish to save and read like that (or you'll have to duplicate the functions with modifications),

- if the only file anyone could possible want to save to is called "data.doc". If you need a file with a different name, you'll need to modify the functions,

- if the desired error response is close-down. What if in your program there was both data that is vital to the program and data that you could do without? What if failing to save some data was not a big problem? What if there were more sensible ways to deal with the problems, such as asking the user to pick another file, clear a read-only attribute, free disk space etc?

What if you want to save the data to multiple files? Heaven forbids you should have multiple arrays which go into different files!

On the other hand:
1) if the file-name was passed as a parameter, you'd be able to save and write to a file with any name you like,
2) if the data was passed as an argument as well - oh boy - you write code once and it works for different arrays!

I have actually programmed in a language that doesn't support passing arrays to functions. Yes, that means if you have a sort routine, you can sort only one array in a program - without code reduplication - and basically for every program you'd have to waste time replacing the name and type of the array - rather than taking a ready-made function from the shelf and simply using it.

Which is, what I believe reusability is all about. Your code, however, cannot be used under different requirements without modifications. That means - zero reusability.

As to the data sharing ideas: if you have multiple processes reading and writing to the same file at the same time, wouldn't that cause problems: data corruption or random crashes if the file gets locked?

------------

As to the general quality and extensibility of your code. Take a look at your poker routine and think for a minute what would it take to make it satisfy slightly different conditions. E.g more than one player? Variable or simply different constant hand-size?

Now, wouldn't it be nice if you could make these changes by changing just the value of one or two variables / constants? Or perhaps by changing a value in command-line or ini-file without having to recompile?

And guess what - it is possible to write code like that! Starting every project from scratch or doing massive amounts of tedious find-and-replace and copy-and-paste is not the only way to modify the behaviour of your programs.

----------------

The bottom line is that I have seen no generality in your code. All your code is hardcoded with a very specific use case in mind. In fact your functions are misnamed, they should be properly called

Code:

void save_pname_to_data_doc_or_terminate();
void read_pname_from_data_doc_or_terminate();

to reflect properly what they do. That is, they do not read or write data, they read and write the contents of one specific array.

Whereas if you coded properly, parts of the name would move into arguments, and the _or_terminate part would become the return value so that the caller can decide what is the most appropriate error response in the context of the call (which the function cannot know about). More importantly, this makes parts of the name variables which means that the same function can be used under much more versatile conditions without a single change.

I can prove 'mathematically' that statement is incorrect
as I can supply numerous programs which have function which do no return
anything, I have even posted some here earlier.

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.

I am not making that claim so I don't need to.

I thought you might say that. Well, I am not making the claim so I do not need to either

So, what claim would you like to make concerning global variables?

But do you hinestly believe that it is possible to quantify conventional thinking, in order to prove it mathematically?

Shh... I'm trying to get esbo to prove something "mathematically" about a stylistic and good/bad practice issue.

Originally Posted by esbo

OK lets start with the first 6 words of that post.

"A function must always return something."

I can prove 'mathematically' that statement is incorrect
as I can supply numerous programs which have function which do no return
anything, I have even posted some here earlier.

So...... can we establish whether you accept that statement is incorrect
before moving on.?

A yes or no answer would be most helpful.

People frown upon lots of things but that in itself is meaningless.

The thing that you apparently don't realize is that if no return type is specified, the function defaults to returning int (and I'm not sure if it is standard any more, at least my compiler would issue a warning about that). That means that your functions can be used like that

Code:

int i;
i = datasave();

However, since you don't return an int, i would now contain some garbage value. (Again, if you turned on compiler warnings, you should see that it complains about reaching the end of a non-void function without returning something.

OTOH, if the function specified that the return type is actually void, the above snippet wouldn't compile - you can't use the return value of a void function (because there is none).

No you can just rename the file.

hmm... but you cannot, since anon specified that "you need a file with a different name".

The code was written to do a job and it did it very well.
I could make it multi purpose but I have no need to.
...
You only need to give it the functinality it needs to work.
If you need to modify it in the future you can, but you might need to so why waste your time?

Normally, I would applaud such a statement. Indeed, a function should do one thing and do it well. Likewise, one should write just enough code to meet the requirements. On the other hand, what you have done is to cripple the flexibility of the code from the start.

I think that hardcoding the filename as "data.doc" is fine. It was an example, so you do not need to be so flexible as you do not have to meet such requirements. However, by the use of global variables, your functions are now tightly coupled to the dataptr and pname variables. Sure, this does not necessarily hurt extensibility, but it does hurt reuse.

You can argue that these functions will never be reused in this example program. That may be true, but unlike hardcoding a filename, this example is an example of poor design: there is no space for possible reuse, despite the fact that allowing for such reuse also accomplishes the goal of writing just enough code to meet the requirements. Why fix the code to use those two variables alone when it could be written to vary, and yet use those two variables?

So the problem is not with the function but with you using it incorrectly.
You can hardly blame other peoples mistakes on my function!!

Actually, we can blame other people's mistake on your function: you stated that your function returns a type of int. Oh, you didn't? Well, you did, since its return type was not stated explicitly, so it defaulted to a return type of int (assuming this is still standard, and not just some undefined behaviour). It is your mistake, fair and square.