We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


Just beginning.

SLaYaH asked
Medium Priority
Last Modified: 2010-04-15
I want to learn programming on all levels. The problem is I am just starting out and considering C language programing is where I should start I want to know what is my first step in learing this language. Should I get some book, is there programs that I can download to help, or is there web sites that will help me. If you can help direct me in the right path I would be greatful.


Watch Question

I'll post this as a comment, not an answer. If you like it, let me know and I'll give you a "formal" answer.

I've also started C/C++ not too long ago, so I know the pains of learing C/C++. I would reccomend the following steps:

1) Get a good compiler - Borland of Microsoft -  if you can afford it. If you have a buggy compiler you'll go mad trying to sort out problems in your program that's not really there!
2) Get a good book on the C++ language, preferably one that that is up to date on ANSI C++ standard. To see some reviews on C/C++ books, try www.accu.org. They have an extensive collection of reviews.
3) Work through the book systematically AT YOUR COMPUTER. Try ALL the examples for yourself, and don't be afraid to play around a bit with problems/examples. Learning C/C++ is a hands-on expercience!
4) Ask questions! Friends, here, other websites, etc.
5) Don't give up. Learning C/C++ (especially if it's your first language) can be though going - but you'll get there.

You can also find a lot of information and resources from the large search engines like Yahoo or Excite (look at their own categories)

I hope this helps!

Good advice.

Get a compiler with useful, understnadable warning messages.
The MetaWare compiler is good for this (messages are clear and also indicate which column the error occurred at).  

It's also important that you develop on a system that doesn't fall over every time you run a program with a bug in it.  This rules out DOS and Windows 3.1.  Use NT or some version of Unix (Linux) if you can, that way you won't be rebooting all the time.

A good book is essential.  At all costs avoid books by Herbert Schildt.  Otherwise, choose one you can read and which has examples, preferably with hints or sample answers.

Some people don't buy the Kernighan & Ritchie book because it's only 250 pages or so, but I have to say this is an advantage.  K&R cover the whole language in that book, and so if you're looking for some information wouldn't you rather search through 250 pages than 1000?

A last point; you must write actual programs to learn a language effectively.  They don't have to be big, or do anything amazing, of course.

All the old timers are going to come out of the woodwork and lay their prejudices on you with this question, slay.

Here's my prej..., uh, advice:

1) Buy/Warez the Microsoft Visual C++ compiler.  Ignore other compilers, they are false gods my child
2) Ignore C++ until you are proficient in C.  C++ re-uses nearly everything you learn in C (it's a ''better'' C), so take it in two steps so as not to bite off more than you can chew.
3) Unless you are forced to use Unix, ignore advice to munge up your head with its cryptic command-line spells.  Stick with a mainstream OS like Windows '95 or '98 and leverage your existing familiarity
4) You will find there are two compilers provided with the Microsoft Visual C++ product, a 16-bit one and a 32-bit one.  The 16-bit compiler is Evil, my child!  It will gnaw on your mind like a starving rat injected through your ear!  You will be lost in the wilderness of Memory Models, unable to touch anything larger than 64K without agony, fear, and (far *)!  Trust in the 32-bit Gods, for they will allow you to touch 4GB without any coughing up blood.
5) All books are crap.  Yet you need books.  Aiieee!!!  Buy/borrow/shoplift at least three books covering the same subject.  What is as clear as mud in one will be clearer in the other two (on average).
6) The advice above about running/compiling code yourself is essential.  You can't learn this stuff just staring at a book, you have to suffer properly, whipping yourself senseless with typos, busted syntax and recompiles until you learn the One True Path.
7) When you start to become experienced, worship the God of Struct.  (This will make sense later).  Only those who follow The God of Struct can pass unharmed into C++-land.
8) Don't figure you must be stupid if you can't get something.  Everyone who answers questions here daily gets reminded how little they know/how many mistakes they make in their work, even if they're old and bald, uh, experienced.  Try to get more than one answer to your question if it's a tough question for you.
9) Examine other folks' source code for tips on how they do stuff

Feel free to ask simple low-point specific questions on e-e as often as you need to.


10) Also examine other folks' source code for tips on how NOT to do stuff.  The difference will become clear when you've read a variety of people's code.
Having just dissed Herbert Schildt, I'll give a list of C authors that I reckon are good.
Andrew Koenig, Harbison & Steele, Steve Summit, Al Stevens, King, Kernighan & Ritchie, PJ Plauger.   There are many other good authors, but no C programming bookshelf is complete without at least one book from the above authors.

Consistently good publishers: Prentice-Hall, Wiley, Addison-Wesley.

Publishers I personally avoid buying from: Sams, Wrox Press.

A good page on learning C is at

Some other resources (some are "advanced", though):-

first,  I would get a good compiler ( I prefer borland, but that is me).   Then I would get some coke, gum, and a comfy chair,  sit down and start learning.  Pay attention to the advice above. They all pretty much cover things.

I advice you to learn Pascal first it is a very easy language and if you learn it you can understand C language very queckly.

Pascal is a powerfull language. Moreover Delphi is a windows version of Pascal.

Motaz from Sudan.


DAH!  Grrrrrttttzzzppptph!  Do not learn Pascal or Delphi (doh!)  This is some Sudanese plot to destroy the Youth Of America by getting them to by Inprise products in revenge for blowing up their baby food factory.

Stick with C and you can move up to C++ and Java leveraging what you already learnt.

The "bible" of C is, of course, K&R2 (also known as "The C programming language" 2nd edition by Kernighan and Ritchie).  It contains almost everything there is to know about C in a conscice matter.

While I have nothing but respect for Andy (warmcat), I must disagree with his remarks.

>> 1) Buy/Warez the Microsoft Visual C++ compiler.  Ignore other compilers [...]
The latest MS givt to humanity (VC++ 6) is not something to write home about regarding the ANSI/ISO standard C++ compliance (same level as version 5).  Other vendors will do better soon.  Also there are free compilers (gcc, gpp, etc) that take up less resources on your system.

>> 2) Ignore C++ until you are proficient in C.  C++ re-uses nearly everything you learn in C (it's a ''better'' C), so take it in two steps so as not to bite off more than you can chew.
The worst C++ code in existence is written by people who treat C++ as just "better C" or "C with classes".  C++ requires a different approach for the problem.  It is recommended to have at least a passing aquaintance with a "pure" OO language (like smalltalk) in order to apapreciate C++'s strengths and weaknesses.

>> 3) Unless you are forced to use Unix, ignore advice to munge up your head with its cryptic command-line spells.  [...]
Today, in the age of X/windows and emacs-based environments this comment only shows that it's author is not up to date with Unix tools.  Just get the tools that run under your platform of choice.  This has nothing to do with C or any other programming language.

>> 5) All books are crap.
Spoken like a true illiterate.

>>  Buy/borrow/shoplift at least three books covering the same subject.
Get K&R2.  You don't need other books.  Just try to solve every excercise in the book and then some (well, there is "The C answer book" that contains solutions to those excercises but that really beats the point, doesn't it?)

>> 6) The advice above about running/compiling code yourself is essential.
This one advice redeems Andy.

>> 7) [...] Only those who follow The God of Struct can pass unharmed into C++-land.
Only those who are able to temporarily forget the old ways of structured programming and embrace the light of object-oriented THINKING will be good C++ programmers.

>> 8) Don't figure you must be stupid if you can't get something.
Ask lots of questions.  C has some very confusing features.  C++ has only confusing features.

>> 9) Examine other folks' source code for tips on how they do stuff.
Beware that path, there be dragons (and contless examples of bad programming practices).

Now, some more advice:
* C is full of pitfalls.  Learn them.  Know thy enemy.
* C has several "cute" or "clever" tricks.  Do not succumb to temptation!  Avoid them unless you have no choice.

While I have nothing but undying love for alexo, and want to have his babies, I have to point out that one doesn't give the same advice to a newbie on Day 1 of learning C, as one does to, for example, Alexo.  So please reparse what I said in that light, and you might go easier on it.  Particularly the struct thing, which is a critical C-side-of-the-river steppingstone on the journey to realising the point of much of C++'s stuff to do with classes (a struct and a class having much common ground in C++).  Having advised the guy to ignore C++ for now, I'm hardly going to give him the full-voltage OO indoctrination propoganda.  Not, at least, if I want him to listen to me.

'All books are crap' was a little too strong... 'all books are crap in parts', or 'all books will let you down', or 'one book will not answer all your questions' would be better.  Anyhow, do I really sound illiterate :?)  But your advice on worshipping just K&R is unrealistic.  In the real world, unless you are made of metal, learning this vast pile of stuff requires the student to hang on by his mental fingertips, hourly wondering if he should give up, filled with fear and feelings of inadequacy.  An explanation that seems 'clear' to the author, and to readers who already knew what is being explained, can be gobbledegook to the student.  Getting the explanation restated more than one way is a great tip when you're stuck understanding the first explanation.



I am going to approach this from a different perspective.  If you wish to approach the problem with insight and clarity, you are better off to:

1)  Set a goal for yourself.  Define exactly what it is you wish to accomplish at some specific point in time.  For example,   "I want to write a killer tic-tac-toe game in Windows that I will put out as shareware"

2)  Figure out what it takes to make it to that goal.  You need to have verifiable milestones, things which you can say you are on your way to your goal and then you will know when you have reached the goal.  For example:

  Goal:  write a Tic-Tac-Toe shareware for Windows
           1)  By The end of the month I will have the tools necessary to get started

           2)  Pick a language.  Do you want to use Delphi? C? C++?  

           3)  Buy the compiler (if you buy you will get support).  (I would go with www.inprise.com or Microsoft)
                I don't agree with warez at all.  If you go down the warez route
               you are supporting piracy of software and then when you finish your product,
               why should anyone buy it?  if you use warez, then the pirates have the right
              to pirate your product.

           4)  Design what and how your program is supposed to work.
                Figure out who is going to use it.  How they will interact with it.  Will there
               be the option of playing against the computer?

           5)   Now look at the design you have and get a bunch of post it notes.  Give each note a specific name that corresponds to the major pieces of your design.  For example in our case you might have a post-it for a 'player'   and another for 'computer player' and another for 'human player'.  You may also have one for the 'engine' (engine is what drives and has the logic)

           6)   Now use your 'notes' to derive modules .   Most of the compilers on the market now support this sort of stuff directly.  With Borland, (inprise) if you get the 'together/c++' option you can put your modules in graphically and it will generate the initial code for you.

          7) Set time/dates when each module will be done

and so on.

Finally, you will need support.  You can get it here at EE and will probably do just fine.

Did you know that if you approach a problem from a pattern perspective that you can make the solution in any language?  A lot of people think OO and then think Eiffel, or Smalltalk, or C++.  But there is much more to it.  OO can be done in any language.  One of my colleagues invented OO Fortran.   I introduced a rudimentary approach to OO (Object oriented).  In the long run OO is the best way to solve a problem.  languages can be learned later.

Unlock this solution with a free trial preview.
(No credit card required)
Get Preview

If you have Visual C++ 5.0 you should try the webside :

Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a free trial preview!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.