brewbuck

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.

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.

Masterx

Great stuff tanx dude

enjoy

thank you for this perfect code ...

nakedBallerina

Begging to differ on the act of commenting code.

I try to make myself comment every line as I code. Actually, I've had more than one instructor and/or associate insist that such is the best practice.

The best practice actually may be a bit backwards.

Start with pseudo-code. (I'm just sure you all pseudo-code first. (couchchokespit))
Then put your actual code in right next to the pseudo-code. By doing this your code is pretty much commented already.

Dale L

matsp

I personally don't think it makes sense to comment on every line of code - comments should clarify what the purpose of the code is and quite often a sequence of say 5-10 lines is self-explanatory once you understand why the sequence is there, with "special" things commented on the line, e.g:
I agree, you need to have some idea how the code should be implemented, either as pseudo-code, or as a design sketch that describes in "plain English" how it all works [at least roughly].

--
Mats

__________________
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.

Salem

Comments (for students) tend to emphasis knowledge of the language as much as anything.
Comments for pros are really just to explain what isn't obvious from just reading the code.
Play to your audience basically - there is no set style.

__________________
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
Up to 8Mb PlusNet broadband from only £5.99 a month!

swliang

perfect !

bertking2

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?

whiteflags

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.

vart

You have never provided support for your own code? Or worse - code written by someone else?

If you do - you will always try to find "that kind of time" to write comments at least...

__________________
If I have eight hours for cutting wood, I spend six sharpening my axe.

Andre Santos

Great thread.

Snafuist

Once programmers enter the level of mediocrity, they tend to forget about all those good advices like "always use comments", "think before you start" and so on. Everybody knows that his own code is obvious and perfect, so why waste time?

Saying that developers are happy if they get it to work at all and have it shipped is maybe true if they're writing a web-based calendar in PHP or if they are working at Microsoft. But consider a company that builds an operating system for a nuclear power plant, or maybe just the software for the airbag in your car (as a friend of mine did for BMW). You don't want these people to ship the code as soon as it works, right?


There are good reasons these advices are passed around, so let's see why:


1. USE COMMENTS

This is true for beginners and advanced programmers alike. Comments make it easy for others to understand your code, and as soon as the project increases to, say, 10.000 (2.000.000) lines of code, it will also be much easier for you. There is a line between "impossible" and "give me 5 minutes", and if it comes down to it, you can only cross it with comments.

But there's even more to it: if you are used to attach a comment to each of your functions, you are forced to think about what you did and how/why you did it. I've found more errors in my own code by writing comments than by testing/debugging. Which leads directly to my next point:


2. THINK BEFORE YOU WRITE

A common mistake among beginners is to blindly start typing characters in their text files and then wonder why the compiler/machine has a different opinion about the code's semantics. In the traditional waterfall model of software development, the time spent on actually producing the code is about 10-20% of the overall development time. The rest is thinking (>70%) and fixing errors (10% to 20 years). At university, we had to develop a small game (actually, a 3D-, networked, multiplayer game). We spent about 4 weeks thinking about the design, layout, necessary methods, classes and their relationships (yes, we were using C++), and when we were ready, it took us about 4 days to implement it in 20.000 lines of code. By then, we were all complete beginners at C++. When was the last time you wrote 20.000 lines of code from scratch nearly error-free in 4 days?


So, don't listen to people telling you to not invest further thinking in your own code.
Use your head.
Gets you ahead.

Greets,
Philip

Bladactania

Amen. And a program doesn't need to be 10,000 lines before it gets confusing if you don't document/comment. A program of just a couple hundred lines can be confusing. Especially to someone else or to you a couple weeks after you write it.

userpingz

A good tutorial for me.
I just read the white bible (K & R) in this morning.
there is no "ctype.h" inclued at the book smaple code. :-)

__________________
--------------------------------------------------------
Newbie
C/C#/C++
swimming/cycling/running
There is nothing more powerful than an idea.
Except for an idea put into action.
--------------------------------------------------------

roaan

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