(Please don't top-post. I've rearranged your reply.)
Steph Barklay wrote On 08/23/07 16:49,:
Steph said:
Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes.
[...]
Two possibilities occur to me. First, you may have
misunderstood what the teacher said (the blame for this
could lie on either side, or on both). [...]
I dont think I misunderstood, here are the course guidelines quite clear
about this.
"During this semester, all programs submitted for homework or extra
credit and the project must conform to the following programming
standards:
1. Use of global variables is prohibited
Ask whether you're allowed to make exceptions for
stdin, stdout, stderr, and (on some systems) errno. (Or,
if you don't want to seem a nit-picking pedant, don't.)
2. All variables must be in lower case, with clear and concise names
that depict what data the varible will contain.
There's a conflict between conciseness and descriptive
power. There's another conflict between descriptive power
and ease of reading.
3. All constants must be in uppercase
So, no lower-case character literals? (See earlier
advice on nit-picking pedantry.)
4. Use of global constants, such as PI, is permitted
I wonder what he means by "global constant." It's
not a phrase used by the C Standard. He might mean macros,
but he might mean file-scope variables with `const'. It
makes a difference.
5. Use of function prototypes is prohibited. As such, all functions
must appear in reverse order of use, with the function main() being
the last function in the program.
Aha! We come to the crux, which is that the writer
of the guidelines has used the word "prototype" incorrectly.
He's trying to forbid forward declarations -- equivalently,
he requires that the only declaration of a function shall
be its definition. This is sometimes called "Pascal style,"
where functions can only call functions that are defined
earlier or are in libraries. (This raises some problems
with mutually recursive functions, by the way: If f() calls
g() and g() calls f(), which appears first?)
However, "prototype" doesn't mean "declaration." A
"prototype" is a particular way of describing the parameters
a function takes, e.g.
/*********************/
int func(int this, double that) { ... }
/*********************/
The highlighted portion is the prototype of the function's
argument list. This is in contrast to the older "K&R style"
of function definition
int func(this, that)
int this;
double that;
{ ... }
In this form there is no prototype. What he said is that
you should use this outmoded syntax, but I doubt that's
what he actually meant.
6. Internal documentation for programs must include data range
specifications for each variable.
7. Before each function a short narrative must be included that
describes the purpose of the function, pre-conditions that must exist
for the function, what data the function returns and by what method
the data is returned, and who developed and programmed the function
which must, include email contact information..
It seems overkill to include your contact information on
every lousy little qsort() comparator, but ... If your
teacher has a bee in his bonnet, you tolerate the buzzing or
risk getting stung.
8. At the top of the main source file, a narrative must be included
that describes the purpose of the program, who was the principle
programmer on the programming team. If the program went through
several revisions, a revision history must be included.
The word is "principal," not "principle."
The reference to "main source file" is interesting, as
it implies the existence of programs that have more than one
source file. Given the prohibition against declarations that
aren't definitions, it is not at all clear how the functions
in one file are to call functions in other files. I suppose
you could (under some circumstances) just #include all the
other files into the compilation of the main file, but that's
a pretty silly way to write C programs.
9. If "include" files are used, each "include" file must conform to
items 1 to 8."
General impression: The guidelines require some good
practices, but they go overboard on occasion and in a few
cases (notably the mixup about prototypes) they mis-state
their intent. Their probable intent, I guess I should say.
