c89 for "strictness" and readability?

Fast code is important, but without rigid rules a beginner programmer can write slow and unreadable code.
What is the best C standard that is explicit (not sugar coated with abstractions) and allows for assembly integration?

c89 forces you to declare functions first, and this separation between declaration and definition looks to me as very readable and explicit...
Also since it doesn't sugar coat anything, it allows for better understanding on what is under the hood (the assembly it generates).

Am I wrong? Hopefully an expert programmer can direct to the right path. Thank you. :redface:

C89 is a 30 years old standard. Why would you still want to use it? I don't understand your sugar coating analogies in this context.


Take the most recent OS for the best implementation of the C runtime library.
Take the most recent C compiler for the best assembly generating.
Give it the instruction to optimize your code for better performance.
Give it the instruction to warn you about everything it is able to find. You get warned for free and you get warnings at compile time.
Use a good debugger. And since it is particularly easy in C to write code with memory leaks, maybe use a memory debugger like Valgrind.

This will all not replace learning to program and gathering experiences in programming (which is not restricted to a certain language or language standard btw.).

After 30+ years of C coding I don't think it really matters what standard you choose to target. People will always be able to write unreadable code, especially beginners.

The best advice would be just to ensure you have turned on all the compiler warnings, and have your code compile without any warnings.

In fact I think the opposite may be true. People who try to use every nook and cranny of a given standard will use features that a lot of people will not be intimately familiar with, and in doing so cause themselves and others grief later on.

Quote:

---

Originally Posted by corgmode

c89 forces you to declare functions first, and this separation between declaration and definition looks to me as very readable and explicit...

---

I have no inclination to check to be absolutely sure, especially since my copy of C89 is like this giant text file that I may or may not still have in a backup, but I don't think C89 actually forces the programmer to declare functions first since the "default int" thing from the distant past may still be in effect, i.e., if a function is called without its declaration being visible at the call site, it is assumed to have parameters of type int with a return type of int. I'd guess that later versions of the C standard either don't support the "default int" thing, or compilers tend to be more strict about it, or maybe its the same and your specific reason is therefore null and void either way, though since I am not in the habit of calling functions such that their declarations are not visible at the call site, I cannot say for certain without checking once again.

Quote:

---

but I don't think C89 actually forces the programmer to declare functions first since the "default int" thing from the distant past may still be in effect, i.e., if a function is called without its declaration being visible at the call site, it is assumed to have parameters of type int with a return type of int.

---

Correct, C89 allowed "default" values, which usually causes hard to find problems.

Stick with one of the newer standards, (C11 or higher) these newer standards have removed several sources of some of the major problems like this and have even removed some functions from the standard, ie gets().

Also as already mentioned make sure you tell the compiler to enable more warnings. By default most compilers just report warnings specifically required by the standard, not the many of "optional" helpful warning/error messages.