 Up to now, I've defined all of my functions before I call them in the main function, as in this program. The C compiler requires you to define a function before you call it. Here, calc subtotal is defined as requiring an integer and a double as its parameters. When the compiler gets to the function call, it can check to see that I have the correct number of arguments. If I would leave out one of the arguments and try to compile, it would tell me I have too few arguments to that function. Let's put things back to the way they were. There's one disadvantage to defining functions at the beginning and main at the end. These functions are the details and main gives you the big picture, and sometimes you want the big picture to come first. What happens if I move these functions to the end of the file and build? When the compiler encounters this line, it recognizes that you are calling a function. It's an implicit declaration, and it tries its best to guess what you want. When it gets to the actual definition of the function, it doesn't find anything matching that guess. The question becomes, how do we put the main function at the beginning and still keep the compiler happy? The answer is to use a function prototype. A function prototype specifies the function's return type, name, and argument types. But not the function body. Here's the prototype for calc subtotal. It returns a double. Its name is calc subtotal, and it needs an integer and a double as its parameters. There's no function body. We end the prototype with a semicolon. Similarly, here's the prototype for calc sales tax. It returns a double. Here's its name. And it requires a double as its parameter. No function body. Just a semicolon. This is all the information the compiler needs to know about these functions in order to check that you're calling them correctly. Now when we build, there are no more errors, no more warnings. You can also name the parameters in your function prototypes. Those names don't have to match the names in the function definition, but it's a good idea if they do. In fact, the easiest way to make sure your function prototypes are correct is to copy and paste the first line of the function definition. The style guidelines for this course will be to always name parameters in a prototype. Why? Consider this prototype for a function that calculates monthly payments on a loan. You can guess that the int parameter is the number of years, but is the first parameter the principal or the annual percentage rate? If I name the parameters in the prototype, there's no question of which one is which. In this program, I put the prototypes at the beginning of the file. But they can go anywhere before the first call to the function. You can put them at the start of main. You can even put them just before you make the first call to the function. But I don't recommend this. It really doesn't help your code's readability. The book I'm using at the time I'm recording this video puts prototypes at the beginning of the main function, even when the functions have been defined before main. If you always use prototypes, this gives you maximum flexibility to place your functions in any order. However, make sure that your main function is always at the beginning of the file or at the end of the file. Putting main in the middle of the file is considered extremely bad programming style. My preference is to use function prototypes only when necessary, when the call to the function comes before the function definition.