How to write C code

[Markdem]

Hi all,

This may seem like a silly question, but does anyone know of any text that covers how to write "good" code? I don't mean how to write the code as such, but more about how to design good and solid logic and flow for the program. I hope that make sense.

I am just trying to learn how to write better code then the normal spaghetti I normally output

Thanks

Mark

[temtronic]

"Good" code could mean 'looks nice to those who see it'.
Consistantly well commented code is easy to read...
Having 'fuses' as an '# include' file makes the 'main' program easier to read,especially for PICs like the 4550 !
Naming files like drivers to 'myLCDdvr.c', 'myRTCdvr.c' can cleanup the overall 'look'.
Same sized variables 'look' nice(learned that from COBOL).
Having comments at the end of very line with same tabbed spacing ,presents a very nice look(typical of assembler programs).
Have an 'include' to define every I/O pin for the PIC you're using(projectPNZ.c).
I find the less 'clutter' and more consistant the code looks the easier it is to read and spot faulty logic,mispelled words,etc.
By creating a core of common 'drivers' or 'setup' files that you always use, you'll spend less time rewriting code since you know those 'modules' work and time can be spent on the main task.
When creating projects,start with a 'template' or 'base' code,save as myPROJECTv1.Then reload,save as myPROJECTv2,make changes,test,save.Keep doing this(v3,v4,...) that way you'll have an easy way to go back 1,2,3 versions to redo code.Also, it gives you several backups in case the power fails !When finally happy, just delete all but the v1 and say the last 2 or 3 versions.It's too bad MPLAB doesn't have a 'delete a project option'...
Hopefully this will help....

[SherpaDoug]

Find some "good" professionally written code and study how it is put together. Note you get to define your own "good" and not all professionally written code is "good".

Also look at MISRA C, which is intended to high reliability.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[asmallri]

[rnielsen]

One thing that helps to keep track of the various variables is to name them to match what they are doing. For instance, instead of declaring int8 x, p, i; and so on declare things like int8 counter if your are using it to count how many times an ISR has been entered, or int8 minutes, hours, seconds; This will greatly help you keep track of what's going on.

You, almost, can't have too much commenting on what your code is doing. I don't know how many times I've had to go back into a program, that I had written a couple of years prior, and needed to re-familiarize myself with what I was doing. Commenting helps me to remember what each section of the code is doing.

Ronald

[Ttelmah]

Also using names that 'remind' you of what the variable type is. It used to be 'standard' to use names like:
fp_counter, and int_counter, as reminders of what the variable actually holds. Particularly in C, this can be a really useful reminder when dealing with calculations of the arithmetic type that will be used.

Best Wishes

[Gabriel]

hi,

Proper indentation of the lines helps me alot too...
especially when you have serveral nested loops or ifs...helps keep track of the brackets and flow of things.

i try to write small functions instead of a loooong doit all block of code...
this helps when testing too because it helps you find the errors . . . this should be one of the first things you learn.... IMO.

naming your functions to match their task....

i like to indent my comments so that they all start in the same place..

like:

[RF_Developer]

Great tips so far!

Making your code look tidy and read well is very important. Comments should add to any reader's understanding, not merely parrot the code in normal language.

But, learning how to structure code: how to put it together, how to "design" it is another matter. Too many beginners worry about "how to design good and solid logic and flow for the program" when they should perhaps think much smaller. What I mean is stop thinking in terms of this big program thingy, and instead deal with functionality step by step. Try to think in terms of modules that do sensible things that you can deal with easily, putting relevant code together in one place rather than spread out here and there all over the place. I always try to seperate functional elements out into manageable chunks. If I'm measuring something I will have one bit of code getting the reading from, say, the ADC. I'll have another bit of code that processes the data, say filtering and scaling or something, and another bit of code that outputs, or stores it or whatever is called for. All to often - we see it here time and time again - these elements are all done in one hit. That makes code difficult to read, hard to change and difficult to debug.

I find driver code really useful as others have said. The first bit of code I wrote for my last project was a driver for a new I2C quad channel DAC. It made the addressing much simpler (I've got three chips, each with four channels - twelve in all). Add in a temperature compensation calculation routine and a remote ADC reading module I'd done earlier and most of the code was done :-) Simples. But then, I've done a lot of coding over the years and it all comes pretty naturally.

So, try to think in smaller chunks. "Wire" or "plumb" the tested and working chunks together later. Keep it simple. Don't try to write the whole program in one go. Don't even think of it that way.

Have a go. If it doesn't work, simplify it and try again. Code is not finished when there's nothing left to add: its finished when there's nothing left to take away.

RF Developer

[Markdem]

Thanks guys, there are some great tips.

I am good at commenting and splitting up the code into functions as much as I can. I know first hand how much work it is going back to a project after 6 months and trying to work out what the hell I was thinking when I did that.
Drives that are very flexible are also one of my favorites. I like been able to too something without recoding.

Is there anywhere that I can find code from something like a engine control system or process controller? Something that has a lot of conditions that have to be met for something to happen, or not. I would love to see the code for the auto-flight system in a aircraft, but what chances have I got there....

The more I think about this, the harder it is to work out what I am asking for