Learn C Programming

4.4 (5 reviews total)
By Jeff Szuhay
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Free Chapter
    Running Hello, World!

About this book

C is a powerful general-purpose programming language that is excellent for beginners to learn. This book will introduce you to computer programming and software development using C. If you're an experienced developer, this book will help you to become familiar with the C programming language.

This C programming book takes you through basic programming concepts and shows you how to implement them in C. Throughout the book, you'll create and run programs that make use of one or more C concepts, such as program structure with functions, data types, and conditional statements. You'll also see how to use looping and iteration, arrays, pointers, and strings. As you make progress, you'll cover code documentation, testing and validation methods, basic input/output, and how to write complete programs in C.

By the end of the book, you'll have developed basic programming skills in C, that you can apply to other programming languages and will develop a solid foundation for you to advance as a programmer.

Publication date:
June 2020

Running Hello, World!

Computer programming is about learning how to solve problems with a computer – about how to get a computer to do all the tedious work for us. The basic development cycle, or process of writing a computer program, is to determine the steps that are necessary to solve the problem at hand and then tell the computer to perform those steps. Our first problem, as we learn this process, is to learn how to write, build, run, and verify a minimal C program.

The following topics will be covered in this chapter:

  • Writing your first C program
  • Understanding the program development cycle
  • Creating, typing into a text editor, and saving your C program
  • Compiling your first C program
  • Running your program, verifying its result, and, if necessary, fixing it
  • Exploring different commenting styles and using them
  • Employing guided chaos, followed by careful observation for deeper learning

Let's get started!


Technical requirements

To complete this chapter and the rest of this book, you will need a running computer that has the following capabilities:

  • A basic text editor that is able to save unformatted plain text
  • A Terminal window that commands can be entered into via the command line
  • A compiler to build your C programs with

Each of these will be explained in more detail as we encounter them in this chapter.

The source code for this chapter can be found at https://github.com/PacktPublishing/Learn-C-Programming. However, please make every effort to type the source code in yourself. Even if you find this frustrating at first, you will learn far more and learn far more quickly if you do all the code entry for yourself.


Writing your first C program

We will begin with one of the simplest, most useful programs that can be created in C. This program was first used to introduce C by its creators, Brian W. Kernighan and Dennis M. Ritchie, in their now-classic work, The C Programming Language, published in 1978. The program prints a single line of output – the greeting Hello, world! – on the computer screen.

This simple program is important for a number of reasons. First, it gives us a flavor of what a C program is like, but more importantly, it proves that the necessary pieces of the development environment – the Operating System (OS), text editor, command-line interface, and compiler – are installed and working correctly. Finally, it gives us the first taste of the basic programming development cycle. In the process of learning to program and, later, actually solving real problems with programming, you will repeat this cycle often. It is essential that you become both familiar and comfortable with this cycle.

This program is useful because it prints something out to the Terminal, also known as the console, telling us that it actually did something – it displays a message to us. We could write shorter programs in C but they would not be of much use. We would be able to build and run them but would have little evidence that anything actually happened. So, here is your first C program. Throughout this book, and during the entirety of your programming experience, obtaining evidence of what actually happened is essential.

Since Kernighan and Ritchie introduced the Hello, world! program over 40 years ago, this simple program has been reused to introduce many programming languages and used in various settings. You can find variations of this program in Java, C++, Objective-C, Python, Ruby, and many others. GitHub, an online source code repository, even introduces their website and its functions with a Hello World beginner's guide.


Hello, world!

Without further ado, here is the Hello, world! C program. It does no calculations, nor does it accept any input. It only displays a short greeting and then ends, as follows:

#include <stdio.h>

int main()
printf( "Hello, world!\n" );
return 0;

Some minor details of this program have changed since it was first introduced. What is here will build and run with all C compilers that have been created in the last 20 years.

Before we get into the details of what each part of this program does, see if you can identify which line of the program prints our greeting. You may find the punctuation peculiar; we will explain this in the next chapter. Notice how some punctuation marks come in pairs, while others do not. There are five paired and five unpaired punctuation marks in all. Can you identify them? (We are not counting the punctuation in the message "Hello, world!".)

There is another pairing in this simple program that is not obvious at this time, but one that we will explore further in the next chapter. As a hint, this pairing involves the lines int main() and return 0;.

Before we jump into creating, compiling, and running this program, we need to get an overview of the whole development process and the tools we'll be using.


Understanding the program development cycle

There are two main types of development environments:

  • Interpreted: In an interpreted environment such as Python or Ruby, the program can be entered line by line and run at any point. Each line is evaluated and executed as it's entered and the results are immediately returned to the console. Interpreted environments are dynamic because they provide immediate feedback and are useful for the rapid exploration of algorithms and program features. Programs entered here tend to require the interpreting environment to be running as well.
  • Compiled: In a compiled environment such as C, C++, C#, or Objective-C, programs are entered into one or more files, then compiled all at once, and if no errors are found, the program can be run as a whole. Each of these phases is distinct, with separate programs used for each phase. Compiled programs tend to execute faster since there is a separate, full compilation phase, and can be run independently of the interpreting environment.

As with shampoo, where we are accustomed to wet hair, lather, rinse, and repeat, we will do the same with C – we will become familiar with the edit, compile, run, verify, and repeat cycle.



Programs are generated from text files whose filenames use predefined file extensions. These are known as source files, or source code files. For C, the .c file extension indicates a C source code file. An .h extension (which is present in our Hello, world! program) indicates a C header file. The compiler looks for .c and .h files as it encounters them and because each has a different purpose, it treats each differently as well. Other languages have their own file extensions; the contents of a source code file should match the language that the compiler expects.

To create and modify C files, you will need a plain text editor. This is a program that allows you to open, modify, and save plain text without any formatting such as font size, font family, font style, and much more. For instance, on Windows, Notepad is a plain text editor while Word is not. The plain text editor should have the following capabilities:

  • File manipulation: Open a file, edit a file, save the file and any changes that have been made to it, and save the file with another name.
  • The ability to navigate the file: Move up, down, left, right, to the beginning of the line, end of the line, beginning of the file, end of the file, and so on.
  • Text manipulation: Insert text, delete text, insert line, delete line, selection, cut, copy, paste, undo/redo, and so on.
  • Search and replace: Find text, replace text, and so on.

The following capabilities are handy but not essential:

  • Automatic indentation
  • Syntax coloring for the specific programming language
  • Automatic periodic saving

Almost any plain text editor will do. Do not get too caught up in the features of any given text editor. Some are better than others; some are free, while others are costly, and may not immediately be worth the expense (perhaps later, one or more might be worthwhile but not at this time), and none will do 100% of what you might want them to do.

Here are some free plain text editors worth installing on your computer and trying out:

  • Everywhere:Nano, which runs in a Terminal; a moderate learning curve.
  • Linux/Unix:
    • Vim, or vi: Runs in a Terminal; a moderate learning curve. It is on every Linux/Unix system, so it's worth learning how to use its basic features.
    • gedit: A powerful general-purpose editor.
    • Emacs: An everything and the kitchen sink editor; a very large learning curve.
  • Windows:
    • Notepad: Very simple – sometimes too simple for programming – but included in every Windows system.
    • Notepad++: A better version of Notepad with many features for programming.
  • macOS only: BBEdit (free version), which is a full-featured GUI programming text editor.

There are many, many text editors, each with its own strengths and weaknesses. Pick a text editor and get used to it. Over time, as you use it more and more, it will become second nature.



The compiler is a program that takes input source code files – in our case, .c and .h files – translates the textural source code found there into machine language, and links together all the predefined parts needed to enable the program to run on our specific computer hardware and OS. It generates an executable file that consists of machine language.

Machine language is a series of instructions and data that a specific CentralProcessingUnit (CPU) knows how to fetch from the program execution stream and execute on the computer one by one. Each CPU has its own machine language or instruction set. By programming in a common language, such as C, the programmer is shielded from the details of machine language; that knowledge is embodied in the compiler.

Sometimes, assembler language is called machine language, but that is not quite accurate since assembler language still contains text and symbols, whereas machine language is only binary numbers. Very few people today have the skills to read machine language directly; at one time, many more programmers were able to do it. Times have changed!

When we compile our programs, we invoke the compiler to process one or more source files. The result of this invocation is either a success and an executable file is generated or it will identify the programming errors it found during compilation. Programming errors can be a simple misspellings of names or omitted punctuation, to more complex syntax errors. Typically, the compiler tries to make sense of any errors it finds; it attempts to provide useful information for the problem it found. Note that try and attempts are merely goals; in reality, the compiler may spew many lines of error messages that originate from a single error. Furthermore, the compiler will process the entire source code when invoked. You may find many different errors in different parts of the program for each compiler invocation.

A complete, runnable program consists of our compiled source code – the code we write – and predefined compiled routines that come with the OS – code written by the authors of the OS. The predefined program code is sometimes called the runtime library. It consists of a set of callable routines that know how to interact in detail with the various parts of the computer. For example, in Hello, world!, we don't have to know the detailed instructions to send characters to the computer's screen – we simply call a predefined function, printf();, to do it for us. printf() is part of the C runtime library, as are many other routines, as we will see later. The way in which one v sends text to the console is likely different from any other OS, even if they both run on the same hardware. So, the programmers are shielded not only from the minutia of machine language, but they are also shielded from the varying implementation details of the computer itself.

It follows from this that for each OS, there is a compiler and a runtime library specific to it. A compiler designed for one OS will most likely not work on a different OS. If, by chance, a compiler from one OS just happens to or even appears to run on a different OS, the resulting programs and their executions would be highly unpredictable. Mayhem is likely.


Many C compilers for every OS

You can learn C on many computer platforms. Common compilers in use on Unix and Linux OS are the GNU Compile Collection (GCC) or the LLVM compiler project, clang. For Windows, GCC is available via the Cygwin Project or the MinGW Project. You could even learn C using a Raspberry Pi or Arduino, but this is not ideal because of special considerations for these minimal computer systems. It is recommended that you use a desktop computer since many more computer resources (memory, hard drive space, CPU capability, and so on) are available on any such computer that can run a web browser.


A note about IDEs

On many OS, the compiler is installed as a part of an Integrated Development Environment (IDE) for that OS. An IDE consists of a set of programs needed to create, build, and test programs for that OS. It manages one or more files associated with a program, has its own integrated text editor, can invoke the compiler and present its results, and can execute the compiled program. The programmer typically never leaves this environment while developing. The IDE often streamlines the production of a standalone working program.

There are many such IDEs – Microsoft's Windows-only Visual Studio, Microsoft's multi-platform Visual Studio Code, Apple's Xcode for macOS and other Apple hardware platforms, Eclipse Foundation's Eclipse, and Oracle's Netbeans, to name a few. Each of these IDEs is able to develop programs in a variety of languages. Nearly all of the programs used in this book were developed using a simple IDE named CodeRunner for macOS.

We willnotuse an IDE for learning C. In fact, at this stage of your learning, it is not advisedfor several reasons. First, learning and using an IDE can be a daunting learning task in and of itself. This task can and should be put off until you have more experience with each of the individual parts of the program development cycle. IDEs, while they have common functions, are sometimes implemented in vastly different ways with far too many different features to explore. Learn C first; you can learn an IDE for your desiredenvironmentlater.


Installing a compiler on Linux, macOS, or Windows

Here are the steps to follow to install a C compiler on the major desktop computer environments – Linux, macOS, and Windows. For other platforms, you'll have to do some investigation to find the compiler you need. However, since those platforms want you to use them, they'll likely make those instructions easy to find and follow:

  • Linux:
    1. If you are running a Red Hat Package Manager (RPM)-based Linux, such as RedHat, Fedora, or CentOS, enter this command from the command line:
      $ sudo yum group install development-tools
    2. If you are running Debian Linux, open a Terminal window and enter this command from the command line:
      $ sudo apt-get install build-essential
    3. Verify your installation by entering this command from the command line:
      $ cc --version
    4. From the preceding command, you will see that you likely have GCC or clang. Either one is fine. You are now ready to compile C programs on your version of Linux.
  • macOS:
    1. Open Terminal.app and enter the following at the command line:
      $ cc --version
    2. If the development tools have not been installed yet, simply invoking the preceding command will guide you through their installation.
    3. Once the installation is complete, close the Terminal window, open a new one, and enter the following:
      $ cc --version
    4. You are now ready to compile C programs on your version of macOS.
  • Windows:
    1. Install either Cygwin (http://www.cygwin.com) or MinGW (http://mingw-w64.org/) from their respective websites. Either one will work well. If you choose to install Cygwin, be sure to also install the extra package for the GNU Compiler Collection (GCC). This will install a number of other required compiler and debugging programs with GCC.
    2. Once the installation is complete, open a Command Prompt and enter the following:
      $ cc --version
    3. You are now ready to compile C programs on your version of Windows.

Compilation is a two-part process – compiling and linking. Compiling involves syntax checking and converting source code into nearly-complete executable code. In the linking phase, the nearly-complete machine code is merged with the runtime library and becomes complete. Typically, when we invoke the compiler, the linker is also invoked. If the compiler phase succeeds (no errors), the linking phase is automatically invoked. Later, we will see that we can get error messages from the compiler either at compile-time – the compiling phase – or at link-time – the linking phase – when all the program's pieces are linked together.

We will learn how to invoke the compiler later when we compile our first program.

Throughout this book, once you have a working program, you will be directed to purposely break it – cause the compilation of your program to fail – so that you can start learning about the correlation of various program errors with compiler errors and so that you will not be afraid of breaking your program. You will simply undo the change and success will be yours once more.



Once compilation has completed successfully, an executable file will be generated. This executable file, unless we provide an explicit name for it, will be named a.out. The executable file will typically be created in the same directory the compiler was invoked from. For the most part, we will make our current working directory have the same location as the source files.

Running an executable file is performed by invoking it from the command line. When invoked, the executable is loaded into the computer's memory and then becomes the CPU's program execution stream. Once loaded into memory, the CPU begins at the special reserved word known as main() and continues until either return; or a closing } is encountered. The program stops and the executable is then unloaded from memory.

To run an executable, open a Command Prompt (Windows) or Terminal window (Linux and Mac), navigate with cd to the directory of the executable file, and simply enter the executable's name (a.out, or whatever you've specified).

Note: If you successfully navigate to the same location as the executable and you have verified it exists there but you get an error message from the command interpreter, you likely have a problem with your command interpreter's built-in PATH variable. To quickly work around this, enter the $ ./a.out command to run it. This instructs the command interpreter to look in the current directory for the file named a.out.

As the program runs, any output will be directed to the Terminal or console window. When the program has ended, the command interpreter will present you with a new command prompt.



At this point in the cycle, you may feel that just getting your program to compile without errors and running it without crashing your computer means you are done. However, you are not. You must verify that what you think your program was supposed to do is what it actually did do. Did your program solve the problem it was intended to? Is the result correct?

So, you have to return to writing your original program and then compare that to the output your program gives. If your intended result matches, your program is correct. You are done.

As we get further into writing more complex programs, we will see that a proper or good program exhibits each of the following qualities:

  • Correct: The program does what it's supposed to do.
  • Complete: The program does everything it's supposed to do.
  • Concise: The program does no more than it's supposed to do and it does so as efficiently as possible.
  • Clear: The program is easily understandable to those who use it and to those who must maintain it.

For most of this book, we will concern ourselves largely with correctness, completeness, and clarity. Currently, hello1.c is not complete, nor clear, and we will see why shortly.



Unlike our shampoo metaphor that we mentioned previously, which was wet hair, lather, rinse, and repeat, instead of repeating the instructions just once, you will repeat this cycle more than once.

Rarely will you be able to go through the program development cycle with only one iteration of it. Most likely, you will repeat parts of it many more times. You may edit the source code and compile it and find that the compiler failed. You will have to go back to edit the source code and compile it, each time figuring out what was wrong and then fixing it. Once it compiles successfully, you will move on to running and verifying it. If the output is not correct or the program crashes, you will have figure out what went wrong and start editing the source code again.

Does this sound frustrating? It can be – especially when you don't know why something went wrong or you can't figure out what the compiler or computer is saying is wrong.

Many, many years ago, when compilers were simpler and not as forgiving as they are today (actually, compilers are still not forgiving – they've just gotten better at figuring out what we humans may have done wrong with our programs and telling us in better ways!), the very first time I attempted to compile my Hello, world! program on a Digital Equipment Virtual Address Extension (VAX) Virtual Memory System (VMS) C compiler, the compiler gave me 23 thousand error messages. It turns out that I had overlooked a single ; somewhere. One character. Sheesh!

The point of that story is that you will make mistakes, mostly missing or erroneous punctuation or misspelled variables, and you will get frustrated. Part of learning to program is learning how to deal with your own frustration and how to become a sleuth to track down the picayune errors that will crop up.

Get up and away from the computer. Take a walk. Have a laugh. Get back to work. Don't omit the first parts (laughing and walking around a bit).


A note about debugging

As you go through the program development cycle and as you get more familiar with the development language, development tools, and yourself (yes, you are learning about yourself as you program), this will all become second nature to you, as it should. When you make a typing error, or when you get an obviously incorrect result, these are not bugs – they are just mistakes. Bugs are far more subtle.

There is a deeper trap that is very difficult for most beginner programmers to see;that is, their own assumptions about what should happen without evidence of what did happen. Most of the most difficult bugs that I introduced in my own code were those that I assumed the program would work on in a certain way but I did not verify that. When I finally went back to my assumptions and proved them in code, I was able to get beyond my self-imposed bugs.

Can you avoid this trap?

Yes. Throughout this book, we will attempt to mitigate this subtle problem with a method we will use to develop programs. As we proceed, we will use trial and error, guided discovery, and evidence through observation. Sometimes, we will purposefully break our programs to see what happens. We will also try to prove each concept so that the expected behavior matches the actual behavior.

This is not to say that even with such an approach, bugs won't creep in. They will. But with careful attention to your own assumptions, observed behavior, and the collection of evidence you have gathered to prove any assumption, most bugs can be avoided.


Creating, typing, and saving your first C program

Let's begin creating our Hello, world! program.

Before we begin creating files, create a directory on your computer where you will save all of the work for this book. Perhaps you will create it in your $HOME directory, or in your Documents folder. My advice is to put it somewhere in a user directory of your choice. Let's go ahead with our program:

  1. Open a Command Prompt, Terminal window, or console (depending on your OS).
  2. Navigate to $HOME or ./Documents, or wherever you chose to work from, and create a directory for the programs you'll write in this book. Do this with the following command:
    $ mkdir PacktLearnC
  3. Make that directory your current working directory with the following command:
    $ cd PacktLearnC
  4. Make a new directory for this chapter with the following command:
    $ mkdir Chapter1_HelloWorld
  1. Make that directory your current working directory with the following command:
    $ cd Chapter1_HelloWorld
  2. Picking the text editor of your choice – any will do – open the text editor either from the command line or from the GUI (depending on both your OS and your preference of which one you wish to use):
    • From the command line, you might enter $ myEditor hello1.c, or just $ myEditor, and later, you will have to save the file as hello1.c in the current working directory.
  3. Enter the following program text exactly, all while paying attention to spacing, {} versus () versus "" (these double-quotation marks are the key next to the ; and : keys) versus <>, with particular attention being paid to #, \, ., and ;:
#include <stdio.h>

int main()
printf( "Hello, world!\n" );
return 0;
  1. Save your work and exit the editor.
  2. Verify that hello1.c exists by listing the directory and verifying that its file size is not zero.

Congratulations! You have completed your first editing phase of the program development cycle.


Compiling your first C program

Having successfully entered and saved your hello1.c file, it is now time to compile it:

  1. In a Terminal, command line, or console window (depending on your OS), with the current working directory the same as your hello1.c file, enter $ cc hello1.c.
  2. Once this is done and you have a new command-line prompt, verify that you have a file named a.out.

You have completed your first compiling phase of the program development cycle.

If the compiler spews out some error messages, try to read what the compiler is telling you and try to understand what error it is telling you to fix. Always focus on the very first error message first; later error messages are usually the result of the very first error. Then, go back to the editing phase and see where your entered program is different than what has been shown here. The two must match exactly. Then, come back to this phase; hopefully, your program will compile successfully (no error messages).

As we progress through this book, we'll add more compiler options to the cc command to make our life easier.


Running your first C program

Your hello1.c program successfully compiled and you now have an a.out file in the same directory. It's time to run it! Let's get started:

  1. In a Terminal, command line, or console window (depending on your OS), navigate to the directory that holds a.out.
  2. At the command prompt, usually indicated by a $ in the first column, enter ./a.out.
  3. You should see Hello, world!.
  4. If you see that, we can now verify the output of your program.
  5. Note that the command prompt, $, is not on the same line as Hello, world!. This means you correctly entered \n in the output stream. If not, you need to re-edit hello1.c and make sure \n occurs immediately preceding the second ", recompile it, and rerun a.out.
  6. If Hello, world! is on a line by itself with a command prompt before and after it – woohoo! You did it!

It's always important to remember to do a little dance, and make a little joy, get down tonight! when you've successfully completed something. Programming can be very frustrating, so remembering to celebrate even your small successes will make your life a little bit more joyful through all the frustration. Too many programmers forget this incremental and regular step of celebrating with joy!


Writing comments to clarify the program later

A lot about writing good code is writing code in a consistent manner. Consistency makes it somewhat easier for the reader (or you) to comprehend at a later time. Consistency is most often a good thing. However, there may be times where we need to step out of that consistency, and for some goodreason, when we write code, that code is particularly twisted or obtuse and difficult to understand. Or, we might write code a certain way that may not be obvious or may not be expected, again for good reason. It is in these circumstances we should comment on our code – not for the compiler, but for ourselves and for others who may be reading our code at a later date, scratching our/their foreheads thinking, "What? What did I/they intend to do here?"

Code comments are the way to provide an explanation of why a particular piece of code is written in a certain way. Let's explore some of the different ways we can write code comments in C.

Comments in code, when done correctly, are ignored by the compiler. They are only for human edification. Consider the following code comments:

/* (1) A single-line C-style comment. */

/* (2) A multi-line
C-style comment. */

* (3) A very common way to
* format a multi-line
* C-Style comment.

/* (4) C-style comments can appear almost anywhere. */

/*(5)*/ printf( /* Say hello. */ "Hello, world!\n" );

/*(6)*/ printf( "Hello, world!\n" ); /* Yay! */

// (7) A C++ style comment (terminated by End-of-Line).

printf( "Hello, world!\n" ); // (8) Say hello; yay!

// (9) A more common way
// of commenting with multi-line
// C++ style comments

// (10) anything can appear after //, even /* ... */ and
// even more // after the first // but they will be
// ignored because they are all in the comment.

The comments illustrated in the preceding code are not particularly useful comments, but they show various ways comments in C can be employed.

Comments with tags (1)(6) are old-style C comments. The rules for these are simple – when a /* is encountered, it is a comment until a */ is subsequently encountered, whether it appears on the same line or several lines later. / * (with a space between them) and * / (with a space between them) are not valid comment indicators.

C comments that have been adopted from C++ are shown with tags (7) through (10). When a // is encountered, it is a comment until an End Of Line (EOL) is encountered. Therefore, these comments cannot appear anywhere like C comments can. Likewise, / / (with a space between them) is not a valid comment indicator.

C comments are more flexible, while C++ style comments are more obvious. Both styles are useful. We'll use both throughout this book.


Some guidelines on commenting code

One of the best guidelines for commenting in code is the same guideline to follow in life. This is sometimes called the Goldilocks Principle, also known as the Three Bears Principle, named after the children's fairy tale, Goldilocks and the Three Bears. The essence of this guideline is not too much; not too little; just right. However, just right is subjective, depends on several factors, and will be different for each situation. Your own judgment and experience must be your guide to your Goldilock's moment.

These are essential guidelines to follow when commenting your code:

  • Assume the reader already knows the language: You are not teaching your reader how to code. Do not explain the obvious features of the language. You are explaining the non-obvious aspects of your code.
  • Write in full sentences with proper capitalization and punctuation: Comments are not code. They are the words you are writing to yourself or to other readers of your code. Your comments will be much less cryptic and more easily understood if you follow this guideline.
  • Comment on unusual uses of the language: Every language has oddities and idiosyncrasies that may not be used often or may be used in unexpected ways. These should be clarified and highlighted.
  • Try to comment in a way that is resilient to code changes: Very often, as code changes, comments are not necessarily updated to match. One way to mitigate this is to put comments in globs at the beginning of functions or to precede blocks of code rather than them being interspersed within code blocks so that if those change, the comments are still valid. You will see examples of this throughout this book.
  • Comment at a high level: Describe the intent of the code and the way it attempts to solve a problem. This guideline goes hand in hand with the first guideline we mentioned. The higher the level the comments are describing, the less likely they will need to be changed as the code changes.
  • Convey your intent: With your comments, strive to convey the intent of the code you are writing, why the code is needed, and what the code is trying to accomplish. What the code is actually doing should come from the code itself.

I am often surprised when I revisit code I wrote 6 months ago. Too often I find that I am scratching my head asking, why did I do this? or, what was I thinking here? (both cases of too little commenting). I also find that when I change code, I have to delete many comments that are no longer necessary (a case of too muchcommenting). I rarely find that I have commented too much when I have focused on the intent of the code (what was I trying to do here).

At one point in my career, I came across a programmer whose comments were completely divorced from the code that was there. I concluded that this programmer initially intended their algorithm to work one way, but then modified the code so significantly that the comments no longer matched the actual code at all. When I saw that programmer's name in subsequent code, after careful inspection, I more often than not simply deleted the code comments because I found them to be irrelevant. Please do not do this unless you are absolutely certain you understand the code and that the comments do not match the code.

Learning how to effectively comment on code is a lifelong challenge. I do not suppose you will learn this quickly. You will learn this after years of examining your own code and making your code clearer to yourself, let alone making your code clearer to others. As we work through various C example programs, I intend to demonstrate a variety of useful and resilient commenting techniques.


Adding comments to the Hello, world! program

Now that we have explored the various ways we can comment on code and commenting styles, let's copy hello1.c to hello2.c and add appropriate comments.

You can either copy hello1.c to hello2.c with your command interpreter or, in your editor, open hello1.c and immediately save it as hello2.c. Regardless of how you do this, you should have both hello1.c and hello2.c in your Chapter1_HelloWorld directory.

In your editor, modify hello2.c so that it looks as follows:

* hello2.c
* My first C program with comments.
* by <your name>
* created yyyy/mm/dd

#include <stdio.h>

int main()
printf( "Hello, world!\n" );
return 0;

/* eof */

Note how the * at the beginning of each line providing a comment makes it clear that there are several lines of comments in a group; the group begins with /* and eventually ends with */. Compile, run, and verify this program. Be certain you haven't introduced an accidental character here or there, which is always possible and should always be verified.

This is now a complete program. We know from the evidence from hello1.c that the program is correct– it displays our intended message in the way we desire. The first six lines of comments provide minimal information about the program's author and the date it was written. This program's heading information may be simple or it may be more comprehensive. For now, we will keep such heading information simple.

The program itself is so simple that anyone who understands C would know that a simple message is printed. No further commenting is needed here.

Finally, we mark the end of the file with a comment; the only benefit to such a marking is when there are multiple editor windows open and/or programs get very long. This simple demarcation lets humans know we're at the EOF. This final EOF indicator is entirely optional and becomes more of a stylistic preference than a practice with rigorous rationale.

I have found that in every programming language I have used, my commenting style has adapted to the clarity or obtuseness of the given language. When I programmed in assembler language at university or later in an early version of Fortran 4, I commented on almost every line. But for C++ or Objective-C, I found I comment only sparsely or in globs– large sections of comments that explain a concept or programming solution.

Furthermore, even within a given language, when the problem being solved is unusual or I am using a novel approach to its solution, more comments are in order.

In the remainder of this book, depending on the code sample, we'll explore various useful commenting practices that are effective, even when the code is subject to change.


Learning to experiment with code

After we have gotten our basic program to work (woohoo!) we can now turn to learn how to intentionally break it (ouch!) so that we can learn more about what the compiler is trying to tell us. What it is telling us isn't always clear, especially as we are learning.

Once you have mastered the language, there would be little need to do this (yay!). While we are learning the language, however, becoming familiar with the various kinds of compiler error messages is essential and will ultimately save us many hours/weeks of debugging, which may have been prevented early on in the iterative program development cycle. Please do not skip this essential step as you learn C as it will save you many hours/weeks.

So, using the full program development cycle outlined previously, inject the following errors into your source file. When you see the error messages, try to correlate them with what you just did to cause them. After each one, correct the error and recompile it to verify the fix:

  • Remove { from hello2.c. Save it and compile it. What errors does the compiler give?
  • Put { back in its appropriate place and remove }. What errors does the compiler give?
  • There are three other paired punctuation marks: <>, (), which occurs twice, and "". What errors does the compiler give when you remove the opening of the pair and the closing of the pair? Put them back after each experiment.
  • Remove ; from either line. What error messages does the compiler give?
  • Comment out the line return 0; What error messages does the compiler give?
  • Change int main() to int MAIN(). What does the compiler tell you?
  • Similarly, change printf( to printout( . With this error, you should see what linker messages look like.
  • Now, comment out #include <stdio.h>. You should also see linker errors telling you it can't find the printf() function.
  • Return hello2.c to its original state. Compile, run, and verify the program is both correct and complete.

If you get more than 23 thousand lines of error messages from the compiler, I would really like to know. Please email me with the details of your experiments.




You've learned an enormous amount about the program development cycle and setting up your C development environment in this chapter. Getting Hello, world! to compile and run is a far larger accomplishment for beginners than they might imagine. You have a working text editor, a working compiler, and you've begun manipulating programs in a command-line interpreter. You have probably experienced frustration to an extent you've rarely experienced before. I, like many programmers before you, feel your pain. We have all lived that pain. And with luck, I'm here to help take away some of that pain. In the rest of this book, we'll explore ways to optimize this whole experience.

You have begun to learn that programming is about solving problems. While we haven't solved many interesting programming problems yet, you are just beginning your journey from simple programs and problems to far more complex programs and problems. We'll encounter a few of these later.

Furthermore, you are now aware of ways to make your programs clearer to both yourself – especially months after you've written the code – and to others who might later be tasked with modifying your code for new demands.

To be sure, getting a C++, C#, Objective-C, or JavaScript environment up and running would be similar yet subtly different.

In the next chapter, we will go into much more detail about how Hello, world! works and then modify it in some interesting ways to learn about statements, blocks, and functions – the building blocks of larger and more interesting programs.

Woohoo! You did it! Isn't programming fun?

About the Author

  • Jeff Szuhay

    Jeff Szuhay is the principal developer at QuarterTil2 which specializes in graphics-rich software chronographs for desktop environments. In his software career of over 35 years, he has engaged in a full range of development activities from systems analysis and systems performance tuning to application design, from initial development through full testing and final delivery. Throughout that time, he has taught computer applications and programming languages at various educational levels from elementary school students to university students, as well as developed and presented professional, on-site training.

    Browse publications by this author

Latest Reviews

(5 reviews total)
It is very good. Quite complete...
Well written, up to date and helpful.
uma boa ajuda para iniciantes

Recommended For You

Learn C Programming
Unlock this book and the full library FREE for 7 days
Start now