Put your program, subroutines, and functions into separate files. This makes it easier to substitute one subroutine for another when you want to use your program to compute a different solution. It also makes it easier and quicker to locate and correct errors.
Separate files allow you to use the same subprogram for different programs. For example, you may want to compute the same solution using a number of different methods. If you have the exact solution, initial and boundary conditions in separate files, you can use them in all your programs. This ensures that all programs really do use the same conditions.
Sharing subprograms this way reduces the likelyhood of errors, by reducing the amount of code that can have bugs. Having several `identical' copies of a subroutine is not the same! One of these copies might have a typo that the others do not. Or a stray character might have sneaked in. And when you found an error just before the deadline to hand in your work, you probably only corrected the latest version. Try remembering that ten years from now.
If your latest program gives erroneous results, it helps to know that your boundary and initial condition subroutines worked perfectly with the previous program. It allows you to concentrate on the more likely places of error. Conversely, if you do find an error in the subroutines, you will know that you might have to reexamine your earlier results. Hence, their reliability is improved also.
If you change a shared output subroutine to give prettier, more easily understood results, it will improve the output of your earlier programs as well. When you switch to a different graphics package that requires a different data format, you only need to change one subroutine.
To keep the various files of a program together, create a subdirectory for them. Put files shared with other programs in a separate directory, maybe called lib. Later you do not have to search everywhere for them.
When using UNIX, create a `makefile' for your program that builds the executable file from the individual source files. Then, when you change one file, you can rebuild the executable with the UNIX make command. Since make can avoid unnecessary compilation steps, development time is reduced. Also, if you need to rebuild the executable years later, you do not have to try to figure out which files are involved.