File Organization

• Each class is to be defined in its own header file. The file extension must be .H or .h It's a good idea, but not required, to name this file after the class. For example, class Foo would be defined in a file named Foo.H or Foo.h
• Every such header file is to be guarded using the

    #ifndef FOO_H
    #define FOO_H
          .
          .
    #endif
  

  style. This style is used to avoid multiple includes of the header.
• No method is to be implemented in a header file. Implementation belongs in the matching implementation file.
• Each class is to be implemented in its own implementation file. The file extension must be .C or .CC or .cpp It's a good idea but not required to name this file after the class. For example, the Foo class would be implemented in a file named Foo.C or Foo.CC or Foo.cpp.
  
  Note that each class has two associated files -- the definition or header file and the implementation file.
• A header file is to be included in a given file if and only if the header defines an entity referred to in the given file. Do include the header if it defines an entity referred to. Do not include it otherwise. For example, suppose Foo.h refers to an ostream entity and a string entity. Then, definitely do include iostream.h and mystring.h in Foo.h. Now, suppose the implementation file Foo.C refers to an ostream entity, but not a string entity. Then Foo.C should include Foo.h and iostream.h, but not mystring.h. Note that iostream.h is included even though its inclusion is also caused by including Foo.h. Guarded header files keep this from causing multiple definition and your code becomes cleaner and more readable.
• The main function is to be in its own file. The file extension must be .C, .CC, or .cpp It's a good idea, but not required to name the file after the project. For example, the main function for project 3 would be in a file named Proj3.C, Proj3.CC or Proj3.cpp
• The executable for a project must be named after the project. For example, the executable for project 3 must be in the proj3 file. This is very important because the grader will look for that file to run your program. The grader will not run a.out or any other executable. The executable name is controlled by your makefile - get it right. Do not submit your executable, the grader will construct it by using your makefile.

Style

For projects in this class, use the following coding standard:

• Only one private, protected and public section in a class definition. public comes first, followed by protected and private, in that order.
• The friend designation is to be used judiciously. Functions, operators, and classes should only be specified as friend if they are intended as part of the interface to the class they are a friend of. You must pay attention to good design in your projects; you should not be using friend simply to avoid using the proper accessor and mutator functions. Projects which abuse friend will lose points proportionate to the degree of abuse.
• Every data member of a class must be private.
• Avoid global or file-scope variables. You may use const variables globally - nothing else.
• Avoid macros (#define) for constants. Use const variables for constants.
• If a class has any virtual methods, provide a virtual destructor.
• If an accessor is provided for a data member, it must be a const method. Example:

  int getSize() const
  

• If a mutator is provided for a data member, it must return void. Example:

  void setSize(int newsize)
  

  ---

  Makefiles

  Every project must be submitted with an associated makefile. The makefile is to be named either Makefile or makefile, your choice. No other names are acceptable for your makefile.

  The grader will compile your submitted project by typing 'make,' so your makefile must correctly make your project. This includes correct naming of the executable.

  A number of tutorials on makefiles are available. One is the UCS tutorial. Another is an excerpt from the GNU tutorial.

  ---