This is the second article in the Making Sense of C series. If you have already programmed before, you won't get too much out of this particular article. Just skip to the summary or look for the blocks of code.
Put yourself in the shoes of Ritchie et al while they were designing the C
language.
These goals will help guide us through the rest of the article.
You want to organize your code so that your compiler can read it and you can send it to someone else. You can't just give the compiler lines of code on the command line, as sending it to people would be difficult. Since you have to save the code to a tape or a disc for anyone to use it, the only reasonable option for organizing your code is to put it into a file.
Now that you've decided that your code is going to be in a file, you need to tell the compiler which file to use. The most straightforward way to do so is to just provide the name of the file to the compiler on the command line, like so:
$ compiler file
Now, it's probably a good idea to distinguish files written in your language
from other files, so let's add an extension.
Since you're programming in C, let's just add the extension .c to our files.
We should also give a short name to our compiler because typing is hard, so
let's call it cc for C Compiler.
Now, using our compiler should look like:
$ cc file.c
Now that we've figured out how to get the code to our compiler, we should figure out the format of the file.
Since you can make the compiler read a file however it wants and you can
organize the data in the file however you want, you might as well stick to the
standard way we read things (in English, since we're designing C in America).
Unless you use something that will modify the order of execution, the compiler will read your code from top to bottom, left to right, just like in English. Blank lines, spacing, and indentation generally don't matter to the compiler, but they do matter to people who try to read your code, which includes you.
Now that we've figured out how the compiler should read the program, how should you separate out statements?
In English, we use punctuation marks like commas, periods, question marks, etc. to separate statements, so we'll try to use some sort of punctuation. We could use a period, but periods are needed to represent decimal numbers (among other things). We could use a comma, but we normally use a comma for lists, so that won't work. We could use a newline, but we have a bit of a problem: newlines vary from operating system to operating system. The only punctuation mark we have left is a semicolon, so we'll use a semicolon. There's also some history with ALGOL 60 using semicolons, as they used periods to end files, semicolons to end statements within a file, and commas for lists.
When you want to make a statement, you should add a semicolon to the end of the statement so the compiler knows that you want to move to the next statement. You should generally write one statement per line, even though you could write the entire program on one line. If you forget the semicolon, the compiler will likely throw an error and you'll have to find where the semicolon should be.
In the code below, each statement will be read in the order that you would normally read them in English.
first statement; second statement; third statement;fourth statement; fifth statement;
We now have a general idea that we want to write the code in a file ending in
.c that should look like
first statement; second statement; third statement;
and we're going to convert it into machine code by running the compiler and giving it the name of the file we want to compile.
As we move on in the tutorial, we're going to expand upon what we have here while maintaining the general ideas laid out in this program.
Throughout this tutorial, I'm going to need to annotate and explain some of the code within the code itself. So next, we're going to solve another problem: How can we add notes to our code that the compiler will ignore?
Find out in the next article: Comments in C.
