But the values passed into the function affect how the programs runs.
It is simple to see what the effect of a variable is on a program by searching on it
in an editor, however once it disappears into a function it 'disappears'.
Most of the programs I have seen have been 'ruined' by 'good programming practise'
in my opinion. The programmers lose all sense of proportion dogmatically following 'rules'.
If there is a bug, the problem is not with the variable, its with some function that doesn't do what its supposed to do. And functions are a lot easier to debug when you know by looking at the prototype what they can do and what they might change.
If you don't want to rename a variable several times, then don't, that's your prerogative. Why would you do that if you're working on projects alone anyway? That's not a reason to prefer globals.
As soon as you work on a team though, abstraction becomes important so several people can build the software together, without breaking each others code inadvertantly, like through a naming clash, or by wanton use of some unrestricted value. That's really why lots of languages have some idea of scope in the first place.
Are you serious? "The name, documentation, and general project design should make it clear what each variable does. ".
The variable does what it does, the documention etc is what is 'supposed' to do.
What if there is no documentation?
Most variable are not documented.
The only thing which will tell you what a function does is the code.
There may be errors in the design at all levels.
Well thanks for your opinion, but that is a serious drawback that you can't just ignore with some amount of hand-waiving (which seems to be what you're offering in general). What if the variable represents the same value (a function parameter, for instance, versus the argument)?Quote:
I have never really ecountered that as a problem, people don't usually give different variables the same name in a waay which would cause confusion.
Or in the context of my argument, you simply name the global poorly, and someone else names a different variable the same, but with a more restricted scope?
Whatever else you could think of... Local variables make this a non-issue.
I have worked on on a team and not encoutered such problems, I am not even sure what you are talking about in 'abstractation' it's unclear.
Your reasons are very wooly and unclear, "wanton use of some unrestricted value"?
what the heck does that mean?
Yes variables have a scope some global some local, it's a choice you do't have to try and
make all the variables local, as some people do.
The same engineering principle is used in software design to allow programmers to work on big projects without necessarily keeping the entire project in their head at once. In the context of C it has to do with how you design your functions, which would be essentially subprograms, with their own inputs and outputs. Since most functions will accept data, churn on it for a while and then make results, it helps to write those things down somewhere, so you can maintain the program (assuming you write anything useful enough to last a long time). I invite you to attend a virtual lecture for the book, The Structure and Interpretation of Computer Programs, if you don't want to hear it from me.
If you do this as a way of life, then yeah, it's important. You can't work on commercial software without being at least a little organized, because the process is bigger than one person. And yeah, when people learn to program in school, good courses are designed to teach and have students practice these things, apart from rote memorization of language syntax.
Or, if your functions don't return any specific data, then you would document (with comments if there is no formal paper) the inputs of the function; the state it leaves things it worked on; maybe a few example figures to demonstrate the process. These things are all helpful when you return to the program to maintain it, long after you've forgotten its impleentation details. In the same way, it helps others understand your design decisions and how the program works.
You and I are working on a program together. You defined a global string to store input.Quote:
wanton use of some unrestricted value
In an uncharacteristic blunder this variable is
I decide that I need my own buffer for whatever purpose. Perhaps I'm doing some parsing and need to maintain parts of the input. So I write a function. In it, I also name a variable buffer, and now the global is hidden from the scope of that function.
Never underestimate how several people can lower the average IQ in a room. :)
All you really need to know are which variables are external to your code.
These the variables which will interface to your code.
If you were using such a buffer it would usually be given a sensible name eg global_buffer.
You would probably have to declare it external to your code. It's not likely to be an issue.
Well frankly I'm not going to search for the one pathological case that will get you to agree with me. Even if you disagree, it is the way it is. It sounds like to me that you cannot accept what you prefer is rather against the grain, especially since the language you use relies on scope to understand what an identifier means and it's type (well, at least when the compiler looks for a declaration).
Given your bias, you would do yourself a service to reach for an early version of BASIC whenever you need to write something
It is really not a problem for me at all.
It might be for everyone else but that's their problem not mine.
I can easilly write code to fit into a big project.
If there are any scoping problems they will be easy enough to sort out.
It's not something I would want to waste time on beforehand.