A philosophical question for C programmers... (just C... please)
What's the best advice you ever got regarding programming in C?
A philosophical question for C programmers... (just C... please)
What's the best advice you ever got regarding programming in C?
"Compile often; test often."What's the best advice you ever got regarding programming in C?
Soma
Probably how to compile with warning levels turned up. That, or to make it clean and readable. (But I don't think anyone ever actually told me the latter, it's just something I do.)
Quzah.
Hope is the first step on the road to disappointment.
To add more comments (as I didn't comment at all at the time)
CommonTater,
The best advice that I received about programming in C came from a professor who would call a program "wrong" if it were poorly formatted or difficult to read, in conjunction with Paul S. Wang's text: An Introduction to ANSI C on UNIX (isbn: 0-534-14232-X). On page 90, Wang summarized his advice...
The actual advice was given on pages 87-9, but it amounts to what we end up talking about quite frequently with regard to formatting, declarations, naming conventions and comments. Knowing the standards made later discussions easier and most importantly meaningful....
Advice on thinking in C was given. A recommended program-formatting style was also described. These principles form the foundation on which all the elaborate constructs of later chapters will be built. No time spent in their mastery should be considered wasted.
...
I've found that a flowchart has been invaluable, but I'm not completely confident that is exclusively a C issue.
The next most important thing, being familiar with the compiler one has chosen to employ. It is imperative for proper use of any language. Primarily because, messages vary from one to the next and getting settings fine tuned is usually system specific. For example, telling the linker which library to use, or where to find it and such "road blocks" would sometimes make for very long sessions in the laboratory. The professor was very clear about that as well....
Later during the engineering courses, the various sorts of documentation styles were emphasized because it was essential to appreciate the body of work during the maintenance/testing phase. In fact, it would be very difficult, if not impossible, to perform maintenance/testing on large projects with out it. This leads me to a completely separate topic...revision control.
On a side note, I don't mean to continuously quote Wang. His text is a favorite and it easy to get to. I did intentionally omitted his specific advice because there are all sorts of standards out there...not to mention something about copyright lawyers that makes me break out in a sweat.
Best Regards,
Kept the text books....
Went interdisciplinary after college....
Still looking for a real job since 2005....
During the interim, I may be reached at ELance, vWorker, FreeLancer, oDesk and WyzAnt.
Make sure you don't overcomplicate your applications, if there is an automated way of doing something, use it, don't try to make your own way up.
- Do the simplest thing that could possibly work - only consider more complicated routes if the simplest way isn't good enough. (A corollary of this is not to optimize early.)
- Always compile everything with as many warnings and errors as you can turned on (with gcc, at the very least use -Wall and -Wextra) and make sure it compiles without any warnings (with gcc you can use -Werror to turn warnings into errors).
There is a lot of stuff which is just good programming practice, regardless of the language.
But one thing which is rather more C specific is KISS. C has so much flexibility that you can all too easily create monsters that cannot be debugged or changed. Yes, occasionally, you need to get creative for some reason or another, but for the most part, keep it obvious.
A modern compiler with maximum warnings is the minimum.
Anyone working professionally should be using additional tools like these:
Gimpel Software PC-lint Overview
Software Quality and Security Analysis | Coverity
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
c can do anything...
from hacking to kernel design.....
(but i never succeded.)
For me it was "Think first, type later"...
It came from a programmer sitting in his cubical, staring at the ceiling. I asked if there was a problem and he answered: "Nope. Just thinking it through before I commit to it."
Last edited by CommonTater; 05-01-2011 at 07:29 AM.
