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.

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.

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.

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).

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).

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.

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

5. Make that directory your current working directory with the following command:
   $ cd Chapter1_HelloWorld
6. 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.
7. 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;
}

8. Save your work and exit the editor.
9. 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.

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.

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!

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.

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).