Loyola College 2007-08 High School Programming Contest


Loyola College > Department of Computer Science > Dr. James Glenn > HS Programming Contest > Coding Guidelines

Problems are designed so that solutions can be written using concepts from the AP Java Subset. Other concepts may be useful and teams are welcome to employ them. Because of declining use, C++ is no longer supported.

Some problems involve writing static methods that, given an object and other parameters, query the object and produce some output or a return value. In such cases, we will provide the skeleton of the class in which the methods should be added.

Other problems involve adding methods to existing classes. When those methods are mutators (methods that change the state of the object they are invoked on), helper methods will be provided so that teams do not have to work directly with instance variables.

Test Cases

Teams are expected to test their solutions thoroughly. Each problem will have a sample test driver with at least one test case given. For problems in which teams must write a method that takes primitive types or Strings as arguments, adding test cases is simply a matter of adding invocations to the test driver. For example, if the test driver is
public class OozleTest
{
    public static void main(String[] args)
    {
        System.out.println(Oozle.translate("this"));
    }
}
then additional test cases could be added by adding the statements
System.out.println(Oozle.translate("is"));
System.out.println(Oozle.translate("confusing"));
System.out.println(Oozle.translate("eye"));
System.out.println(Oozle.translate("ornate"));

In cases where the arguments passed to a team-written method are objects or where teams are to add a non-static method to an existing class, methods will be provided so that teams can set up the objects as they wish before testing their method. For example, one problem required using a grid with colors such as

8x8 grid all red in upper left quadrant;
one more adjacent red; two blues in lower right

In this case there was a constructor to create an empty grid and a method to draw rectangles in the grid:

public class QuadTreeTest
{
    public static void main(String[] args)
    {
        Grid d0 = new Grid(8);          // makes an empty 8x8 grid
        d0.storeValue(1, 0, 0, 3, 3);   // draws red (color 1) at (0,0)-(3,3)
        d0.storeValue(1, 0, 4);         // draws red at (0,4)
        d0.storeValue(2, 6, 7);         // draws blue (color 2) at (6,7)
        d0.storeValue(2, 7, 6);         // draws blue at (7,6)

	QuadTree t0 = new QuadTree(d0); // team-written constructor
	System.out.println(t0);
    }
}

In this case teams were expected to instantiate their own Grid objects and color them with the storeValue method: adding the code

Grid d1 = new Grid(4);
d1.storeValue(1, 0, 0, 3, 1);
d1.storeValue(2, 0, 2, 3, 3);
QuadTree t1 = new QuadTree(d1);
System.out.println(t1);
would have tested the team-written QuadTree constructor on a 4x4 grid with the left half red and the right half blue.

In such cases there may also be a provided method to read test cases from files. See below of how such cases will be handled.

Input and Output

If input must be read from a file, there will be either a constructor that takes a filename as a parameter, a constructor that takes a Scanner object as a parameter, or a method in the supplied test driver that reads a file and creates an object. In all cases, opening the file and reading the input will be handled by supplied code and teams will not have to know how to use the java.io package or the Scanner class.

Once the data has been read into an object, teams can query the object via its methods to see what the input was. For example, in the grid example from above there was a method provided in the test driver to create a Grid object from data stored in the file. The Grid object was then passed to the team-written code, and that code could use the method int getSize() from the Grid class to return the size of the grid and a method int getValue(int x, int y) to return the color of a given position on the grid.

If teams create their own input files, they should carefully mimic the format in the provided input files. In particular, any special characters (for example, '.' to represent an empty space on a game board) should be used as in the provided input file, and whitespace characters should be used exactly as they were used in the provided input file (generally this means there should be a single space between values given on the same line, no blank lines, and no extra whitespace characters at the ends of lines). Do not count on the supplied input code to detect if the input file is malformed.

Output, when handled by team-written code, will consist of System.out.print or System.out.println statements. When sample output is given in a problem description, it should be assumed, unless it is otherwise stated, that there are no blank lines in the output, and that there are no extra whitespace characters between the last non-whitespace character and the newline character. For example, if the sample output is

Programming Contest
2008
then acceptable code to produce that output would be
System.out.println("Programming Contest");
System.out.println("2008");
but not
System.out.println("Programming Contest  "); // note the extra spaces
System.out.println("2008");
and not
System.out.println("Programming Contest");
System.out.println("2008");
System.out.println(); // there shouldn't be an extra blank line

No other System.out.println statements should be present in the submitted code. If such statements are used for debugging, they should be removed before the code is submitted.

Collections

Generic collection classes are now part of the AP Java subset. Therefore, where any provided code uses the Java Collections Framework, that code will use generics. We may, at our option, also provide alternate ways of using the collections without generics, for example if we provide a method List< Integer > getCodes() then there may also be a method List getCodesHeterogeneous(). Note that if such alternatives are present, then we will get the following compiler warnings

Note: StudentList.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
which can be safely ignored for the purposes of the contest.

Furthermore, wherever collections are used, we will provide a way to access the items in the collection without using the collections classes. For example, we may provide methods to count the number of items in a collection, and retrieve the items by index, so that

List< String > l = students.getNames();
Iterator< String > i = l.iterator();
while (i.hasNext())
  System.out.println(i.next());
and
for (int i = 0; i < students.countNames(); i++)
  System.out.println(students.getName(i));
would behave identically.
Last updated Sun Feb 10, 2008

Valid HTML 4.01 Transitional