From 56wiki

CS56—Advanced Applications Programming—W12

lab02: More Ant, TDD, JUnit (src vs. build)

This week:

• separating src/build, making JAR files
• More TDD of classes, and JUnit
• JUnit with double
• toString methods

Special instructions for those working in a pair

If you are working in a pair and you ALSO worked in the SAME pair on lab01, YOU MUST READ THIS.

We want to STRONGLY ENCOURAGE appropriate pair-partner interactions and DISCOURAGE inappropriate pair-partner interactions. SO:

• Define "A" as the pair partner who was the "initial driver" last week---i.e. you did the lab in As account, and submitted from As account last week.
• Then you MUST work in "B"s account this week and submit from B's account. Otherwise, NEITHER PAIR PARTNER WILL GET CREDIT FOR THIS WEEK'S LAB.
• Also, if we find that "A" is working in "B's" account without B present, or vice-versa (e.g. via inappropriate sharing of passwords), that will be considered ACADEMIC DISHONESTY and we reserve the right on a first offense, to give you a permanent zero on the lab in question, and report the matter to Student Affairs, and to the Engineering system management staff (as a terms of service violation.)
• If a second offense were to occur, we reserve the right to issue of course grade of F for repeated academic dishonesty.

Overview

This lab will build on the material we introduced about Ant and JUnit in lab01.

Previously, we learned...

Previously, we learned how to use an Ant build.xml file to:

• compile source code
• run a main program from a .class file
• include an external "third-party" JAR file (in this case, the JAR file for JUnit) when compiling
• run JUnit tests using the Ant junit task
• generate and deploy Javadoc directly to a website
• make a "clean" target that cleans up the .class files and the generated javadoc, leaving behind only source code

We also learned about the process of developing a Java class using Test Driven Development, via JUnit. Our class had:

• private attributes of type String and int
• a constructor with an argument for each private attribute
• getter methods for each attribute
• a getter that combined two attributes using string concatenation

In the previous labs, we had all of our source code and our "object code" (i.e. the .class files we generated) in one directory. This isn't good practice, and in this lab, we'll start separating those.

New in this lab

In this lab, we will first learn how to separate our source files and .class files into two separate directories. By convention, these directories are called:

• src for the .java source files
• build for the generated .class files

We'll then show take all of the .class files from your build subdirectory and create your own JAR with those, and put your JAR file on the web.

We'll then show how you can run code from someone else's JAR file.

• Note that doing so has certain security risks----so, only do this if you COMPLETELY trust the other person.
• The risk is that the JAR file could do malicious things if you are not careful---like delete all your files, copy malware into your account, or copy private files from your directory into their directory.)
• One way to mitigate (reduce) this risk is to run with a "security policy" that restricts what the program can do. We'll explore how this can be done at the command line via: java -Djava.security.manager className [args]

and via Ant as well.

Along the way, we'll get more comfortable with targets and tasks in Ant.

On the Java side, we'll do more practice with developing classes with TDD and JUnit

• We'll learn about testing doubles for equality using a "tolerance" parameter in JUnit's assertEquals method
• We'll learn about the toString method

Step-by-Step

Step 1: Preliminaries

Start by making a copy of your lab01 directory called lab02. You can use a recursive cp command, like this:

-bash-4.1$ cd ~/cs56
-bash-4.1$ cp -r lab01 lab02
-bash-4.1$ 

Then cd into your ~/cs56/lab02 directory.

Step 2: Change the projectName property

Find the line in your build.xml file that defines the projectName property, and change it from lab01 to lab02.

  <property name="projectName" value="lab02" /> 

Step 3: Moving to having src and build directories

Next, we will change our setup so that there are separate src and build directories:

• src for the .java source files
• build for the generated .class files

Step 3a: Creating the directories and moving the files

Create two directories in your ~/cs56/lab02 directory called src and build:

mkdir src
mkdir build

Then, move all of your .java files into the src directory:

mv *.java src

And issue a similar Unix command to move all of the .class files (if any) into the build directory. (If you don't have any, then this step is not necessary.)

Step 3b: Changes to build.xml so that the build directory gets created as needed

Next, find the compile target, and right before the javac task, if it isn't already there, add this additional task:

  <mkdir dir="build" />

That way, if the build subdirectory does not already exist, your build.xml file will create it automatically. This is really handy—especially if you reuse your build.xml file later on another project. Also, the "ant clean" rule sometimes simply deletes the entire build directory to be sure that no .class files are left hanging around.

Step 3c: Changes to build.xml so that build directory gets deleted when we do ant clean

In the clean target, we need to make the following change:

OLD:

 <delete failonerror="false" verbose="true">                                                                                              
      <fileset dir="." includes="*.class"/>                                                                                              
    </delete>    

NEW:

 <delete dir="build" quiet="true" />    

This old rule deletes all .class files from the current directory (the one that the build.xml file lives in). The new rule deletes the entire build subdirectory. This is better, because—as we'll discover when we start using packages—the .class files for a large project can end up in a complicated directory hierarchy. Deleting the entire subdirectory in which they live is a lot easier than deleting them one by one.

Step 3d: More changes to build.xml (for the separation of src and build

Starting from the top of the file, here are the changes we need to make:

After making these changes, test your build.xml file again by trying all of the following targets at the Unix command prompt:

• ant
• ant compile
• ant clean
• ant test
• ant run
• ant javadoc

Step 4: Ant targets for distributing our code—making a jar file

Step 4a: Understanding what a JAR file is

You have already read about JAR files in the textbook, so I won't give a detailed explanation—the following is just a reminder of the main points:

• If we are writing code for people to actually use, at the end of the day, we need to give them something to run.
• Real world programs or libraries written in Java or C++ typically consist of not just one class, but many classes (and real world C programs consist of many functions). In both cases, these are usually defined in many separate files.
• When using C/C++, what we deliver is an "executable" where all the various functions, classes, methods and data have been linked into a single file.
• With C/C++, we can link the object code for all the various classes and libraries into a single executable file. We can also combine multiple .o files for a library of software routines into an "archive" library file (a .a) file or a dynamically linked library (sometimes called a "shared object", or .so file) that we can link user programs against.
• In Java, there is no exact equivalent to this process, but there is a way to combine multiple classes into a single file that can essentially function either as an executable, or as a library. That combined file is called JAR or Java Archive.
• In Java, we can run a main directly from a .class files, and if other classes are needed, they can be loaded by the JVM directly from the .class file as long as they are in the "classpath". That's fine for testing, but it is inconvenient to deliver a whole directory of .class files to an end user that wants to run our code. So the usual way to distribute a Java program or library is via a JAR file.
• A JAR files is a collection of .class files that is compressed together using the .zip method of compression.
• The JVM knows how to unpack a JAR file and get at the classes inside.

Step 4b: Creating a JAR using Ant

Ant provides an easy way to create a JAR file. If you've already started to pick up on how Ant works, you'll realize that what we are looking for is an "Ant Task" that creates Jar files. And if we look at the list of Ant Tasks at http://ant.apache.org/manual/tasklist.html we'll see that there is indeed a task called Jar (http://ant.apache.org/manual/Tasks/jar.html).

Here's some build.xml code for a target to make a jar. Add this to your build.xml

 <target name="jar" depends="compile">                                          
   <mkdir dir="dist" />                                                         
   <jar destfile="dist/${projectName}.jar" basedir="build"/>                    
 </target>   

This target first uses the mkdir task to create a directory called dist (short for "distribution"—i.e. the directory from which we will distribute both the source code and runnable versions of our code.) The target then uses the jar task to create the .jar file, specifying the directory that contains all the .class files (i.e. the build directory).

Note how we use the ${projectName} property so that the jar file will be named lab02.jar—using a variable here means that we can reuse this build.xml file for future labs while only changing the line that gives projectName its value (be that lab02, or lab04, or whatever.)

This jar target depends on the compile target, since we need the .class files to exist before we can "jar them up" into a .jar file (i.e. a Java Archive.)

Try it now, by typing ant jar at the shell prompt. You should get output something like this:

-bash-4.1$ ant jar
Buildfile: build.xml

compile:
    [javac] Compiling 3 source files to /cs/faculty/pconrad/cs56/lab02/build

jar:
      [jar] Building jar: /cs/faculty/pconrad/cs56/lab02/dist/lab02.jar

BUILD SUCCESSFUL
Total time: 2 seconds
-bash-4.1$ 

If it worked, you should now have a .jar file in your dist directory. We'll see what you can do with that file in just a moment.

-bash-4.1$ ant jar
Buildfile: build.xml

compile:
    [javac] Compiling 3 source files to /cs/faculty/pconrad/cs56/lab02/build

jar:
      [jar] Warning: UCSBCourse.class modified in the future.
      [jar] Warning: UCSBCourseTest.class modified in the future.
      [jar] Warning: UCSBCourseTester.class modified in the future.
      [jar] Building jar: /cs/faculty/pconrad/cs56/lab02/dist/lab02.jar

BUILD SUCCESSFUL
Total time: 2 seconds
-bash-4.1$ 

Step 4c: Adding code to our clean target to remove the .jar file

If we are cleaning up, we may want to remove the .jar file—in fact, we probably want to remove everything in our dist subdirectory. So we can add this to our clean target, right after the task that deletes the javadoc directory:

  <delete dir="dist" quiet="true" />    

Try running the ant clean and then the ant jar and make sure things happen the way you'd expect them to—i.e. that after an ant clean, the dist subdirectory disappears, and then it comes back again when you do ant jar.

Step 4d: What you can do with a jar file

One thing you can do with a jar file is to put it in your classpath, and then you can run programs from inside of it.

For example, the following command will run the main routine from the UCSBCourseTester class, accessing the code inside the jar we created.

-bash-4.1$ java -classpath dist/lab02.jar UCSBCourseTester
(output appears here)

You can also run a jar file directly if you've specified a 'default main' to run from the JAR file (remember that JAR file can contain many classes, each of which might have a main() method.) This is done using something called a manifest (sort of like a "ship's manifest", a document that says what's on board the ship.) Unfortunately, at the moment, our build.xml file doesn't have one—at least not yet. So, if we try to just run the jar file directly, we get an error:

-bash-4.1$ java -jar dist/lab02.jar UCSBCourseTester
Failed to load Main-Class manifest attribute from
dist/lab02.jar
-bash-4.1$

So, let's fix that now.

Step 4e: Adding a manifest using Ant

To add a manifest that specifies the default main to run when using java -jar foo.jar, all we have to do is add a <manifest> element to the ant jar task that specifies the name of the class that contains the main, like this:

    <manifest>
      <attribute name="Main-Class" value="UCSBCourseTester"/>
    </manifest>

This element gets nested inside the jar element, so we can no longer use a self-closing element—we change it from this:

  <jar destfile="dist/${projectName}.jar" basedir="build" />    

to this:

    <jar destfile="dist/${projectName}.jar" basedir="build" >                      
       <manifest>                                                                 
         <attribute name="Main-Class" value="UCSBCourseTester"/>                 
       </manifest>                                                                
   </jar>  

So add this into your build.xml now, and try doing the ant clean and ant jar again—then try this command:

java -jar dist/lab02.jar

You should get output something like this—that is, it should run the main method from your UCSBCourseTester class:

-bash-4.1$ java -jar dist/lab02.jar 
(output from UCSBCourseTester would appear here)
-bash-4.1$ 

There is more we can do with jar files:

1. they can also be used as libraries
2. they can be used to launch applets than run in your browser (which is kind of an old school thing that folks don't do much anymore)
3. they can be used with Java Web Start to launch programs from the web that run on your local computer (not as an applet, but as a desktop app, so to speak)

We'll see all those in future labs—but for this week, that's enough on jars.

     <attribute name="Main-Class" value="edu.ucsb.cs56.w12.pconrad.lab02.UCSBCourseTester"/>                  

Step 5: Making a web page for your project

Once we have the capability to create javadoc and jar files, it is just one more step to be able to copy everything to a nicely formatted webpage.

Create a subdirectory called html in your ~/cs56/lab02 directory. Inside it, create this file, and call it index.html. Where it says YOUR NAME(S) HERE, substitute your name (and if appropriate that of your pair partner also.)

<!DOCTYPE html>
<html>
 <head>
   <title>cs56, w12, lab02, YOUR NAME(S) HERE</title>
 </head>
 <body>
   <h1>cs56, w12, lab02, YOUR NAME(S) HERE</h1>
   <ul>
     <li><a href="download">download</a></li>
     <li><a href="javadoc">javadoc</a></li>
   </ul>
 </body>
</html>

Then, add this little target that will "publish" our javadoc and jar file to the web by copying this index.html file, as well as populating the javadoc, browse and download directories.

(Note that to populate the javadoc diretory, all that is necessary is to make this step depend on the javadoc target.)

<target name="publish" depends="jar,javadoc">                           
   <mkdir dir="${webRoot}/${projectName}" />                                      
                                                                                 
   <copy file="html/index.html" todir="${webRoot}/${projectName}"/>               
                                                                                  
   <copy todir="${webRoot}/${projectName}/download" >                                                                           
     <fileset dir="dist" />                                                       
   </copy>                                                                        
                                                                                  
   <chmod dir="${webRoot}/${projectName}"                                         
          perm="755" type="both" includes="**/*"/>                                
                                                                                  
   <echo>Project published to ${webBaseURL}/${projectName}</echo>                 
 </target>           

Try running "ant publish". If it works, you should be able to go to http://www.cs.ucsb.edu/~YOURUSERNAMEHERE/cs56/lab02 and see something like this (with your name and username in place of mine (note S11 instead of W11, lab02 instead of lab03):

And, furthermore, if you click on the links, reasonable things should happen:

• the download link allows you to see a link where you can download the .jar file
• the javadoc link shows you the javadoc

If you got that to come up, you can move on to the next step.

Step 6: Copy two new files into your ~/cs56/lab02/src directory

Keep the UCSBCourse.java, UCSBCourseTest.java and UCSBCourseTester.java files in your src directory, and to them, add the files you find at this link:

http://www.cs.ucsb.edu/~pconrad/cs56/12W/labs/lab02/code

You can copy these:

• using a cp command from ~pconrad/public_html/cs56/12W/labs/lab02/code/*
• using a wget command on each file's URL
• doing a "save as" from the web browser, if your web browser is running on CSIL

Step 7: Look at the new code we've copied in

Here are your three programming tasks for this lab:

(1) ComplexTest.java: This file contains JUnit tests for another typical Java class: this time a Complex number with a real part and an imaginary part. The JUnit tests check the operation of a couple of constructors and some getters and setters, and a toString method. There is nothing you must do in this file except read and understand the tests.

(2) Complex.java: This file contains ONLY the Javadoc comments that hint at what you should write for methods. To truly know what methods to write, you'll need to consult both the Javadoc comments AND the JUnit tests in ComplexTest.java. In this file, you (obviously) need to fill in the methods---FIRST with stubs, so that they compile, but the tests don't pass---THEN with code that compiles and passes the tests.

In addition to a constructor with args and getters, this week we also have:

• a no-arg constructor,
• setters for attributes, and
• a toString method. (There is more information on the toString method later in this lab description.)

(3) Now, following the example of the toString method for Complex.java, add a test and an implementation for a toString method for UCSBCourse.java.

The format of the toString method should be as follows:

• CMPSC56: "CMPSC56: Advanced Application Programming (4 units)"

So, now you are just about ready to get to work. Steps 7a, 7b, and 7c contain some helpful hints on completing these tasks.

Step 7a: A few notes on the toString method

You already realize from CS24 (and perhaps from CS32) that some of the fundamental operations that many classes have are:

• constructor(s)
• getters
• setters

In Java there is one other very fundamental method that you should probably implement for every class you make. That method is the toString method.

The toString() method helps you format how an object prints if we do something like this (assume here that the UCSBCourse constructor shown below takes name and permNumber as its parameters):

Student s = new Student("Phill",1234567);
System.out.println("s=" + s);  

If we don't implement a toString() method, what we'll see that what we get is something sort of ugly. The output might look like this:

s=Student@e13e07

When, what we really want is something like this:

s=(name: Phill, perm: 1234567)

We'll see that we can get this result instead, by simply implementing a method like this:

 public String toString()
 {
     return "(name: " + this.name + ", perm: " + this.permNumber + ")"; 
 }

In fact, just by implementing a toString() method, we can customize how objects appear when they show up in the output of System.out.println and any other time that we want to convert our object to a String. This is a very useful method to have around. It can be of great help to us later in debugging large programs.

Step 7b: Tips on adding stub methods to the Complex class (and for toString in UCSBCourse.java)

Before you are going to be able to compile your code, you are going to need to add stub methods to the Complex class—otherwise you aren't going to get past the ant compile stage.

So start there.

public String toString() {
  return "(" + x  + "," + y + ")"; // + does String concatenation
}

Once you have stub methods for your Complex class, and for the toString method in UCSBCourse, and your code all compiles, but all the JUnit tests fail, you ready for the next step.

Step 7c: Replace all the stubs in both Complex.java and UCSBCourse.java with working code

Ok, now replace all the stubs with working code. If you get stuck, consult the "Tip" box in the previous step.

Once your code compiles and passes all its tests, you are just about done.

Step 8: Running someone else's code

Now, we'll show that you can run someone else's code, and they can run yours.

Step 8a: Add a System.out.println to your UCSBStudentTester program

To the main method of your UCSBStudentTester program, add a line like this (with the appropriate substitution):

System.out.println("This program is by @@@INSERT YOUR NAME HERE (IF WORKING ALONE) @@@");

or

System.out.println("This program is by @@@INSERT YOUR NAMES HERE, BOTH PAIR PARTNERS@@@");

Then do "ant compile" and "ant publish" to put your new JAR file out on the web.

Step 8b: Find another individual or pair partner in the course that you trust

It is important that you trust this individual (or pair)—even though we will be taking some security measures to avoid any "malware", you still don't want to run closed source code from folks you don't trust.

You are going to add a target to your build.xml file that runs their code, and they are going to add one to their build.xml file that runs your code.

Find out the CSIL username of the the full path of their home directory, and share yours with them. You can determine this path in one of two ways:

1. A user can issue a "cd" command to get to their home directory, then type "pwd" at the Unix prompt.
2. You can use the unix command "finger username" to find the user's home directory.

Examples:

-bash-4.2$ cd 
-bash-4.2$ pwd
/cs/faculty/pconrad
-bash-4.2$ finger kyleklein
Login: kyleklein      			Name: Kyle T Klein
Directory: /cs/student/kyleklein    	Shell: /bin/bash
Last login Thu Jan 19 10:40 (PST) on pts/47 from 169.231.127.203
Mail forwarded to kyletklein@gmail.com
No mail.
No Plan.
-bash-4.2$ 

Step 8c: Add this property and this target to your build.xml file

Now add this property at the top of your build.xml file. Here /cs/student/surfer03 is the home directory you obtained in Step 8b.

<property name="trustedFriendsHomeDirectory" value="/cs/student/surfer03" /> 

And add this target.

  <target name="runfriendscode" description="run my trusted friends UCSBCourseTester program">
    <java classname="UCSBCourseTester"  fork="true">
      <jvmarg value="-Djava.security.manager"/>
      <classpath>                                                                                                                              
         <pathelement location="${trustedFriendsHomeDirectory}/public_html/cs56/lab02/download/lab02.jar"/>                                                   
     </classpath>              
     </java>
 </target>

Read over this and see if you can figure out what it is supposed to do, and how it works. For each of the items below, identify which part of the XML code does the item in question:

• The runfriendscode target consists of one task, a java task.
• The java task has one attribute specified on the open tag, fork="true". This is necessary because we are going to be using the Java Security Manager, which requires us to create an new instance of the Java Virtual Machine.
  • By default, the java code we run is executed in the SAME virtual machine that Ant is running in. (Recall that Ant itself is just a Java program, so the JVM is already running when the Ant software is processing your build.xml file.)
  • That's fine in some cases, but in other cases, it creates a problem.
• The java task runs the class UCSBCourseTester
• The nested jvmarg element says that we want to invoke the java.security.manager to prevent unsafe operations (e.g. writing to the file system).
  • This provides partial protection against evil code that might do something nasty to your files. To be specific, it tries to run the "trusted friends code" in a "sandbox"; the same "sandbox" used for Java Applets. However, this protection should not be considered 100% reliable; there is always the possibility of exploits. This is why I'm emphasizing the words "trusted friend" here.
• The nested classpath element indicates where we are getting the jar from that contains the code we are going to run

Step 8d: run the target (i.e. "ant runfriendscode")

Now make sure that when you type the following, that it runs your friends UCSBCourseTester program:

ant runfriendscode

It should look something like this:

-bash-4.2$ ant runfriendscode
Buildfile: /cs/faculty/pconrad/cs56/W12/lab00/build.xml

runfriendscode:
     [java] This program is by Gina Gaucho and Sammy Slough
     [java] Test 1 passed
     [java] Test 2 passed
     [java] Test 3 passed
     [java] Test 4 passed

BUILD SUCCESSFUL
Total time: 2 seconds
-bash-4.2$ 

If so, you are done! (Though you might, as a courtesy, want to help out your trusted friend, to make sure that he/she can run YOUR program too!)

Step 9: turnin

Before you proceed further, check over the items in the rubric at the end of this lab file to ensure that you didn't leave anything out that would cause you to lose points!

• It is best to do this in pair-programming fashion, with one partner reading the checklist, and the other checking the code.
• Even if you "solo programmed" this lab, you may want to see if you can find someone in the lab that also solo programmed, and ask him/her to be a "rubric buddy" with whom you can take turns doing this checklist step.

Also, from now on, do an "ant clean" before you run the turnin command.

That is, before doing turnin, cd into your ~/cs56/lab02 directory (if you are not already there) and do the command:

ant clean

This will clear out your directory of everything except the essentials---what should be left is pretty much only your src code subdirectory, the build.xml, and the html subdirectory.

Then, cd up one level to your ~/cs56 directory and use the command:

turnin lab02@cs56 lab02

This will turnin the entire contents of your lab02 directory.

Then, after you do the turnin, do the ant publish step one more time and check the web just to ensure everything is online and up-to-date.

Grading Rubric: Total Points: 300

Partial credit may be awarded for each step at the discretion of the TA/Instructor.

Mechanics

• (5 pts) Executing the turnin step on a directory called lab02
• (5 pts) Having five .java files named UCSBCourse.java, UCSBCourseTester.java, UCSBCourseTest.java, Complex.java, and ComplexTest.java under a src subdirectory in your submission. (Not at the top level directory!)
• (5 pts) No build subdirectory is present in the submission, because you did a clean first before submitting
• (5 pts) There is a build.xml file in your submission
• (5 pts) There is an html subdirectory that contains an index.html file.

Complex.java

All of these must pass tests, be written in good style, and have appropriate Javadoc comments to get full credit.

• (10 pts): no arg constructor
• (10 pts): 2-arg constructor
• (10 pts): setter for real
• (10 pts): setter for imag
• (10 pts): getter for real
• (10 pts): getter for imag
• (20 pts): method that converts to a String representation

UCSBCourseTest.java

All of these must pass tests, be written in good style, and have appropriate Javadoc comments to get full credit.

• (10 pts) Everything required from lab01 is present
• (10 pts) A new test for toString was added

UCSBCourseTester.java

All of these must pass tests, be written in good style, and have appropriate Javadoc comments to get full credit.

• (10 pts) A System.out.println line was added per instructions

UCSBCourse.java

All of these must pass tests, be written in good style, and have appropriate Javadoc comments to get full credit.

• (10 pts) Everything required from lab01 is present
• (10 pts) A new implementation of toString was added

Build.xml

To get full credit for any item in this list, the item must be present, AND must do its job correctly.

• (10 pts) build.xml file has all elements required from lab01 (except where modifications were specified in lab02)
• (5 pts) step 2: change project name property
• (5 pts) step 3b: add mkdir for build directory
• (5 pts) step 3c: change clean to remove build directory
• (30 pts) step 3d: six items as per instructions
• (5 pts) step 4b: creating jar target
• (5 pts) step 4c: clean should remove jar file
• (5 pts) step 4e: adding manifest to jar file
• (5 pts) step 5: add publish target
• (5 pts) step 8c: add property for trusted friends home directory
• (5 pts) step 8c: add target to run friends code

Web page

The web page and its contents (deductions of 5-10 points may be made for each item from list below that is not completed)

• (5 pts) html directory exists inside submitted lab02 and contains index.html
• (5 pts) html/index.html file contents look reasonable
• (5 pts) file is available on the web at http://www.cs.ucsb.edu/~username/cs56/lab02
• (5 pts) ant publish target copies that to the web
• (5 pts) student's web page has javadoc and download links that link to correct content (javadoc for javadoc, and jar file at the download link.)

General Good Practices

• (25 pts) Following Instructions
  • If there is anything that you should have done that was in the instructions but isn't already covered elsewhere in the grading rubric, these points are the ones that are "at risk" for those items.
  • Late submissions ALWAYS lose all of these points--and are subject to receiving a zero if the TA has already finished grading the assignment before the submission is received. TO ENSURE THAT YOU GET CREDIT, SUBMIT BEFORE THE DEADLINE.
• (10 pts) Coding Style
  • By this point in your programming career, you should know about things like using good variable names, indenting properly, factoring out common code into a subroutine, etc. Anything that is an obvious defect in your code is something that TAs have discretion to deduct points for, up to the amount specified for this item.

Due Date

You should do your best to complete this within the assigned lab time during week 3 of the quarter.

If that is not possible, then you should complete the assignment and execute the turnin command no later than 5pm Friday of week 4 of this quarter. This gives you one full week to seek help during office hours from both the instructor and the TAs, plus one additional lab period to ask the TAs for additional help.

Submissions turned in after that time are subject to receiving zero credit.