I think that when you reach a certain level of experience you know what to do and what not to do.
So in a beginners point of view i think this is a good example, and the main point that i see is
1. Write one line
2. Compile
3. Fix error(s)
4. Write another line
Instead of copy - paste 200 lines and then wonder why nothing is working..
Also i suggest anyone to maybe start with more highlevel languages such as PHP (which has similar syntax and function-names as C), just to get the big picture.
Last edited by mog; 08-15-2007 at 06:45 AM.
But that's a purely syntax-based approach. Just because your program compiles doesn't mean it's not full of errors. Eventually you get the hang of the language and don't make syntax mistakes anymore -- or only rarely -- but that doesn't mean your code is bug-free.Originally Posted by mog
I'd suggest that you should write code non-stop until you run out of ideas. As soon as you find yourself thinking, "Hmm. I'm not sure how to do this next part..." that's a good time to stop and compile. This avoids creating a break in your concentration. The result will probably be a thousand syntax errors -- that's OKAY. Just look at the first one, and go fix it. Recompile, and repeat. Don't try to fix all the errors in a single pass. Often times, many errors all stem from a single typo. You may find that 3 different typos can create hundreds of errors.
Avoiding the break in concentration is very important while in the learning phase. Switching between problem-solving mode and syntax-fixing mode can be taxing.
From a beginners standpoint myself, learning to write C for an embedded platform, i have found that having a number of syntax errors promotes understanding of the platform becaus you need to traverse through a number of peripheral libraries to find the function you have declared or written incorrectly.
--dave
perfect !
developing code
The coders who have it right are the ones who document at all stages - before, during, after - especially before.
If you don't do it before, then regardless of how accomplished you think you are, your middle name is always 'Spagetti', like Joe 'Spagetti' Smith. If you DON'T know what you are going to code BEFOREHAND, and can't or won't explain it to yourself, you are in deep doo doo from the first line of code onwards, because you are lazy.
Actually writing the code, is like painting the house you built. DO IT LAST !!!
Start with an architectural drawing, plan out the construction, get the right tools, make a solid foundation, build a sound structure, ensure the fundamentals for expansion are in place, finish the plan - according to the plan ... then paint it. If you did things right, you can modify, reconstruct or rebuild things, and still meet code standards. Else call "Holmes on Home" to rescue you.
It is easy to paint and repaint a solid wall or ceiling, right?
Last edited by bertking2; 07-04-2008 at 03:08 PM.
I'm not one for speaking in metaphor, but developers usually don't have that kind of time. Their goal is if they can get it to work at all, get something shipped.
It's good for newbs to plan because they'll become more familiar with language tools, and learn how to make/follow a program spec. It does get easier.
Great thread.
Simply fantastic !!!!! I always used to wonder how those big lines of codes are written but now i know the secret too !!!!!!! Thanks a lot
