CIS 110 Spring 2013 - Introduction to Computer Programming

upenn.edu | directories | van pelt library
seas.upenn.edu | CETS | engineering library
computer graphics & game dev (SIGGRAPH @ Penn) | dining philosophers (DP) | science & tech wing (STWING) | women in cs (WICS)
CETS Answers
CIS 110 Course Policies

Overview


Introduction to Computer Programming is the first course in our series introducing students to computer science. In this class you will learn the fundamentals of computer programming in Java, with emphasis on applications in science and engineering. You will also learn about the broader field of computer science and algorithmic thinking, the fundamental approach that computer scientists take to solving problems.

Lecture and Recitation

There are three lectures a week, MWF 10-11 (first section) and 12-1 (second section) in Towne 100. Slides will generally be posted on the lectures page before or shortly after class. Recordings will be posted to the video archive, accessible from the lecture page, at some point after lecture. Recordings are not a substitute for attending lecture: they are not interactive, and show only the computer screen, not the chalk board or demonstrations.

Recitations are held every week on Wednesday or Thursday. They are a critical component, and attendance is required. Recitations review lecture introduce cover additional and related examples, and practice group problem solving. Your recitation TAs are your guide for the course and your first stop for any questions. They also grade your assignments. Contact your TAs during their office hours or via email with any questions, concerns, or comments about the course.

Switching between CIS 110 and 120

CIS 110 is designed for people with no prior programming experience. CIS 120 is designed to build on either the fundamentals learned in 110, a high school class such as AP Computer Science, or independent experience. Because this is not a black-and-white scale, we allow students to switch between classes. If you are not sure which class is right for you, we recommend attending both for the first couple of weeks so you will not need to catch up if you switch.

Grading

The approximate grade breakdown for the course is:

  • Homeworks: 40% (Your lowest homework grade will be dropped)
  • Midterm: 20%
  • Final: 30%
  • Recitation: 10%
  • Staff Discretion: Adjustment for participation, etc.

Each component of your grade is curved independently. Curving is simply a tool to help us assess your performance and to correct for absurdly difficult exams; there is no quota for the number of As, Bs, etc. In past semesters, about half the students have received some sort of A. Many of these students started with no prior programming experience.

If you do better on the final than on the midterm, more weight will be given to your final exam score relative to your midterm to reward your improvement.

Focus on the course material, not on your grade. You will enjoy the course more, find it more rewarding, and most likely do better. We typically provide the median and standard deviation for all exams, and approximate letter-grade cutoffs on the midterm (but not the final, since you get your course grade at the same time as your final exam grade). Aside from this information we do not provide any additional detail on the grading procedures beyond this section. We will not predict what grade you will get in the course, nor tell you what you have to do to get an A. Counting points will not help you get more points, only distract from the substance.

Re-grades

You may request a re-grade for homeworks up to a week after they are returned. Please direct your homework re-grade requests to your TA.

For exam re-grade requests, we will provide exam re-grade request forms for you to fill out. We will announce the deadline for re-grade requests when we release exam grades. Mid-term re-grade requests must be submitted to your TAs. We will provide directions for submitting final re-grade requests when we release the final exam scores. All exam re-grade request must be in writing, and must be accompanied by your exam.

Note that a re-grade can result in a lower score on the problem in question. We also reserve the right to re-grade the entire submission. As a result, your final grade may be lower or higher than your original grade.

Homework and Late Policies

It is imperative to understand that computer programming is not a spectator sport. To get good at it, you need to practice, and the primary vehicle for that is the homeworks.

  • Homework assignments are generally due on Thursdays at 9pm.
  • You have four late days to use as you wish throughout the semester. Each late day allows you to submit an assignment up to 24 hours late.
  • You may use at most two late days on any given assignment. After two days, you will receive no credit.
  • Late days are deducted automatically for late submissions. You do not need to ask permission or give any reason for using them.
  • Assignment submitted within three hours of the original due date will be counted as on time, however they will not be eligible for extra credit. This is a grace period, and does not apply to late days or extensions.
  • Deadlines are automatically enforced. On Saturday at 9:00pm, the submission link will disappear. If you have fewer than two late days remaining, the link will disappear sooner.
  • You may submit as often as you like. We will grade the last version of each file that you submit. Once you have submitted a file, you do not need to resubmit it unless it has changed.
  • If the deadline is approaching, submit! Remember, it is much better to submit an incomplete assignment than nothing.

  • Extensions will be granted only in exceptional circumstances (e.g. extended, serious illness).
  • Extensions are valid only if entered into the system and are visible when you view your grades or submit online. If your extension does not show up with 24 hours, contact the instructor or TA who granted it to make sure it gets entered.
  • You may not use late days or the grace period together with an extension.

TA Office Hours

We offer extensive office hours in the Moore computer labs, and try hard to have as many TAs and mentors on staff as possible to keep wait time short. For Spring 2013, we are greatly increasing the staff to shorten wait times.

The schedule of who has office when is maintained as a Google calendar. We try to update this for last-minute changes, and University holidays, but be alert to piazza announcements of changes as well.

  • Structure of Office Hours
    • If you need help, add your name to the list on the board. We help students in order.
    • At busy times, we may keep several lists for different categories of problems (e.g. different stages of the assignment). This lets TAs and mentors "specialize" in particular assignment areas and help students with the same problem in small groups.
    • Out of fairness to your fellow students, you may only have your name on the board once at any given time. If you have your name on the board more than once at any given time, we will erase all but the last occurrence.
    • Office hours for assignments end at the deadline, not the end of the grace period! On busy days, we will close the help list 30 minutes before the end of office hours.
    • Debugging is unpredictable and doesn't work well in marathon sessions. Start early and start asking questions early, and you'll make steady progress. If you come into office hours with questions about the beginning of the assignment the day before it is due, you should expect not to finish it on time.

  • Getting Help in Office Hours
    • We welcome questions about both course material and homework during office hours.
    • We have a structured process for helping with programming that is designed to be efficient and to help you become independent. Depending on the stage you are in, we will help you in one of three ways:
      1. If your code is not correctly indented, we will tell you to indent your code and move on to the next student (see the style section). Correctly indenting code is akin to insisting you correctly capitalize your sentences before we help you with your spelling and grammar. Your code should be correctly indented at all times.
      2. Assuming your code is correctly indented, we will help you understand compiler error messages so you can get your code compiling. You should compile your code every time you write a new piece (even if it is only two or three lines), and correct and compile errors before continuing. This is analogous to thoroughly checking spelling and grammar every time you finish writing a sentence. It seems pedantic, but turns out to be far more effective than writing lots of code, then trying to compile it.
      3. If your code compiles, we will ask you what happens when you run it. We'll help you work out the best way to test the program and interpret the results that you're seeing. This is the heart of the debugging process, and often the heart of understanding the assignment.
    • We cannot promise that your program is correct in office hours. That is determined during grading. You should always reread the assignment carefully when you're done to make sure your program does precisely what is asked.
    • It may seem helpful to explain to us what you're trying to do, but it usually isn't. Dealing with compile errors in order, then methodically testing, is invariably faster and leads to better comprehension. Remember that computers blindly carry out the instructions they're given in order, without looking ahead; as a result, you can't properly test and debug later steps until the earlier steps are working.

  • Debugging Advice
    • You may wish to copy skeleton code from the assignment into your program. If you do, make sure it is either commented out, or compiles. You cannot debug and test the parts that you are working on if you have included other code that doesn't compile.
    • Similarly, you may wish to "work ahead" on later sections of the assignment while waiting for help. Even if you do so in a separate file, your code should be correctly indented and should compile. Otherwise the code you write will almost certainly turn out to be useless.
    • Don't try to understand the entire assignment all at once. Focus on one step at a time. When you get that working, you will find the next step much easier to understand. The expressive power of programming comes from breaking complex problems into manageable pieces. Most programs are too complex to understand as a whole, and solve problems that are too hard to understand as a whole. This is true even of most programs that are written by a single person!

Coding Style

Just like human languages, programming languages have a particular syntax and grammar. If you make a mistake, you end up with a program that is invalid, or "gibberish." And just as publishers and periodicals have "house styles" that govern how to indent paragraphs, how many spaces to put after a period, which abbreviations to use or avoid, etc., companies and programming projects also adopt style guidelines.

imaginereadingatextwherenothingwascapitalized,therewasno spacebetweenwordsandaroundpunctuationmarks,andparagraphswere separatedbyonlyatinyblankspace.thetextwouldpreserveits meaning,butbenearlyimpossibletoread. Furthermore, if every article (or every paragraph) in a magazine adhered to a completely different style, it would be almost as confusing. Programming is no different, except that it is far easier to make a syntactically correct program unreadable by using poor or inconsistent style. Good style is essential to programming, and a substantial portion of your homework grade will be based on style.

Programming style generally encompasses how you indent your code, when you put spaces around operators, and how you name variables, functions, and classes. There are many opinions about what constitutes the best style, and most companies and projects adopt their own guidelines to ensure consistency. In CIS 110, we follow the textbook's style guidelines. These are typical of the rules you are likely to encounter elsewhere, but represent a particular set of choice among many possibilities. Here are some of the highlights:

  • Indentation
    • Each block of code must be indented 4 spaces to the right of its parent block. A block is any section of code enclosed between curly braces ({}). If you use the introcs installer to set up Dr. Java as part of Homework 0, it will be configured this way automatically. You can re-indent the current line by pressing TAB. You can reindent a whole section by selecting it and pressing TAB. You can reindent the entire file by selecting everything (Cmd-A on Mac, Ctrl-A on Windows), then hitting TAB. Do not indent your code manually with spaces, let Dr. Java do it.
    • There is no excuse for improperly indented code. Ever. Whenever you start typing a new line of code, press TAB to make sure your cursor is in the right place. Whenever you cut and paste, or insert code, select the region around it and press TAB to reindent. Badly indented code is impossible for humans to read, and impossible to debug. If Dr. Java automatically indents your code in a way you don't expect, you have a bug. Usually you are missing a semi-colon or curly brace.
    • If your code is not properly indented in office hours, we may refuse to help you. There is no rule that is more universally agreed upon than the importance of correct indentation. There is also no single, simple thing you can do that will help you more than correctly indenting your code.

  • Variable and Class Names
    • Variable names and function/method names start with a lower-case letter. If the name is a composite of multiple words, each subsequent word starts with a capital letter. For example, "var" is an acceptable name for a variable, and "thisIsAVariableName" is also an acceptable name for a variable. The names "ThisNameBeginsWithACapitalLetter" and "this_name_contains_underscores" are not acceptable for variables in CIS 110.
    • The same rules apply to functions and methods (we introduce functions and methods in the course of the semester). The first convention, that variable names begin with a lower-case letter, is very widely accepted. On the other hand, many projects and companies prefer to separate words with underscores ("_") rather than using capital letters.
    • As an exception to the above rule, constant variable names should be all upper-case. Constant variables are variables whose value never changes. Alternatively, think of these as symbolic names for particular values. The canonical example is a variable whose value is 3.14159... This variable would be named "PI" rather than "pi". This convention is also widely accepted.
    • Class names should begin with a capital letter. If the name is made up of multiple words, each word should begin with a capital letter. Once again, this is a widely accepted convention in object-oriented languages. It is often difficult to tell from context whether a name refers to a variable or a class. By following the capitalization conventions your code becomes much easier to read and understand.

  • Spacing
    • Use a single space on either side of mathematical operators (+, -, *, /). For example, write "x + y", not "x+y".
    • Put a space before an opening curly brace, or else put the brace on its own line. Be consistent in your choice. Put the close curly brace on its own line.
    • Do not put a space before the square brackets for an array. For example, write "String[] args" and "args[0]", not "String [] args" or "args [0]".
    • The spacing around parentheses corresponds to how you would use them in English and math:
      • Put spaces outside the parentheses, but not inside them, when they are used to group mathematical computations. For example, write "a + (b + c)", not "a +(b + c)" or "a + ( b + c )".
      • Put spaces outside the parentheses, but not inside them, when they are part of a loop or conditional (if, for, or while). For example, write "if (x > 5) {", not "if(x > 5){" or "if ( x > 5 ) {".
      • Do not put spaces around parentheses when they are part of a function call. For example, write "System.out.println("hello, world.")", not "System.out.println ("Hello, world.")" or "System.out.println( "Hello, world." )".

We use the checkstyle program to automatically detect many (but not all) violations of the textbook's style guidelines. On most assignments, you will see the output of checkstyle when you submit the program. If there are any warnings that we have not specifically told you to ignore, you should correct them and resubmit or risk a style deduction. Once we cover the terminal/command prompt, we will show you how to run checkstyle yourself, before submitting.

Class Message Board

We use Piazza as our message board system. Piazza is a web service specifically designed for students to post questions about the course and have them answered by the class staff or their peers. We also make course-wide announcements through Piazza, so make sure to sign up for it as part of Assignment 0.

  • Announcements
    • Announcements will normally be made via Piazza as Instructor Notes, and e-mailed to all registered user.
    • Instructor notes will be e-mailed from "CIS 110 on Piazza", and the subject will start with [Instr Note]
    • You are responsible for the content of all announcements on piazza.
    • Announcements will normally also be pinned at the top of the piazza message list until they are no longer relevant.

  • What to Post
    • All questions about course material and assignments should be posted to Piazza rather than e-mailed to your TA or the instructor.
    • Other students invariably have the same questions as you do, and posting them to Piazza encourages discussion amongst you.
    • If you e-mail a question directly to a TA or the instructor, you will likely be asked to repost it to Piazza.
    • We encourage you to post questions publicly as much as possible (you can set your posts to be anonymous to your classmates), and to answer each others' public posts.
    • Answering questions on Piazza is a great way to learn yourself, and we take it into consideration when grading. Finally, don't forget to search the message board before posting. If you haven't searched yet, there is a high probably your post is a duplicate (even if it is about an error in your code).

  • When to Post Code
    • The best way to get programming help is in person, in office hours. However, this is not always possible, and sometimes we need to look at your code in more detail to find the problem, then get back to you.
    • You may post private questions to Piazza that include your code when necessary. To do this select Post To "Instructor(s)" rather than "Entire Class" at the top of the posting form. Private posts are visible to all TAs and instructors, but not other students, so it is safe to post your code this way.

  • How to Post Code And Error Messages
    We need to be able to read the code, and have enough information to help you debug it, so it is import to follow these guidelines when posting code and code-related questions:
    • Do not e-mail code problems to your TA or the instructor unless you are specifically asked to. Post to Piazza instead. We will be able to answer you better and faster that way.
    • Cut and paste the specific compiler error, or the specific test your ran and its output into your message. These error messages may well be cryptic to you, especially early in the course, but they are very specific as to the problem. We will help you understand what they mean, and how to use them to diagnose and solve your problem.
    • Enclose the output you cut and paste between "<pre>" tags like in the example below. There is no special button to enter <pre> tags in Piazza, you simply type them in like ordinary text.
      <pre>
      HW.java:24: class HelloWorld is public, should be declared in a file named HelloWorld.java
      public class HelloWorld {
             ^
      1 error
      </pre>
    • The <pre> tags ensure the output is formatted exactly like in Dr. Java or the Terminal/Command Prompt. Without them, the web browser reformats the text and makes it harder for us (and you) to read.
    • We usually prefer public posts that include the exact error and a description of how it occurred. That way all students can benefit from the question and answer. If we can't answer your questions, we will ask you to either come to office hours or post a private question with your code.
    • Post your code between <pre> tags. If you don't put it between <pre> tags, all indentation will be lost, and we won't be able to read it. This is the most annoying thing about Piazza, and therefore the most important thing for you to remember.
    • INDENT YOUR CODE CORRECTLY! In past semesters, we have received numerous posts with un-indented code (even when we add the <pre> tags). There is no excuse for this, and we can't help you if we can't read your code.
    • Post all your code. Without all your code, we cannot reconstruct the precise situation that caused your error. Bugs are often not where they appear to be, and we can't always help you find the problem if you only post part of your code. Later assignments often consist of several files; post the contents of every file you have worked on.
    • If your post does not contain all the correct information, is not properly indented, or does not have the <pre> tags, click the Edit button and fix it.

    You can access the message board through this link.

    Collaboration Policy

    In a computer programming class, the line between helping and cheating can be blurry at times. We encourage you to discuss assignments and approaches to solving them with each other, but it also important to go through the process of turning this into a working program yourself. So we have strict rules about what you can and can't do:

    • We encourage you to:
        Discuss assignments with one other;
        Develop pseudo-code on paper in small groups;
        Explain the meaning of error messages to each other, as long as you don't look at any other student's code;
        Work on examples related to assignments, including coding them together;
        Sharing test cases and input data that you create, except when creating these is part of the assignment itself.
        You must credit everyone you collaborate with on assignments by name, including fellow students, friends, and tutors. You do not need to credit members of the course staff. If a member of the course staff helps you and other students on an assignment in a group, credit the other students and office hours so we don't accidentally flag your assignments as inappropriate collaboration.

    • You must not:
      • Copy anyone else's code, either electronically or by typing it in;
      • Look at anyone else's code, electronically or on paper, even if they are not currently in the course;
      • Share your code with anyone, electronically or on paper, even after you are no longer in the course;
      • Allow anyone else to copy a file of yours, either explicitly or by leaving your code unprotected;
      • Have someone else debug your code, except members of the course staff.
      • Suspected cases of plagiarism will be referred to the Office of Student Conduct. Plagiarism cases unfortunately arise every year, and the typical punishment is suspension and failure in the course.

    • Use your best judgment.
      • Protect both yourself and your friends. In cases of unwarranted collaboration, all participating parties are typically penalized (both helpers and helpees).
      • Make sure you log out of lab computers and protect access to your code. If it is stolen, you may well still have to go through a stressful disciplinary procedure that will be more punishment than you deserve! You will also have the burden of demonstrating that your code was stolen.
      • Use judgment about asking or answering questions of other students. For example, if you are supposed to implement Algorithm X that is described in the book, and you don't understand Algorithm X, then you can ask another student to explain it to you. However, if you are supposed to come up with your own algorithm to solve a problem, then you may not ask another student to tell you their algorithm.

    Naturally, the course also follows the standard Penn academic integrity code, so make sure that you are familiar with this as well. As a final note, we will periodically run cheat checking software such as Alex Aiken's MOSS to help detect copying. These programs are remarkably good at detecting copying; changing variable names and simple code rearrangements don't trick them. Modifying an existing program to defeat a cheat checker is generally just as hard and requires just as much understanding of the problem as writing your own program from scratch.

    When in doubt, ask the instructor or your TA if the help you are providing is a violation of academic honesty.

    Resources and software

    We use the Java programming language and the DrJava integrated development environment (IDE). Java is a platform-independent, high-level, object-oriented programming language commonly used in the software development industry. For TOY assignments, we also use the Visual X-TOY environment. These software packages are all free, and you will install them as part of Assignment 0.

    Please refer to Homework 0 for instructions on how to obtain and install these software packages for use on your home computer.

    Textbook

    We use the required textbook Introduction to Programming in Java: An Interdisciplinary Approach by Robert Sedgewick and Kevin Wayne. You can purchase the textbook from the Penn bookstore, Amazon, or your favorite bookstore. You may also be able to find a used copy.

    Computer labs

    The University of Pennsylvania provides a number of computer labs for use by SEAS students. All of the SEAS computer lab machines have both DrJava and Visual X-TOY installed by default. The CIS 110 course-specific folder in the start menu contains shortcuts to these programs as well as links to useful, on-line resources.

    You can find a list of SEAS-supported labs on the SEAS computer lab page.

    Tutoring

    Tutoring is available at no charge through the tutoring center. In addition to private tutoring, the tutoring center offers drop-in satellite hours and a weekly review session. See the course schedule page for the times.

    Tutoring is intended to help you understand core concepts that you are struggling with; it is not a substitute for lecture, recitation, or office hours. In particular, tutors are not TAs and are not allowed to help you debug your programming assignments. They can help you understand the concepts behing the homeworks by working through related exercises with you. When you start working with a tutor, you will set specific goals for what you hope to achieve in tutoring, and that will guide your session.

    Questions and comments

    We're here to answer your questions, help you learn, and evolve the class so that current and future students learn why we love computer science so much! Remember that your TA is your first stop for any questions or comments about the class. You should also feel free to contact the instructor with your questions and comments in, before, or after class, during office hours, via Piazza, and via email.

    If you are interested in CIS or one of our related degree programs, feel free to get in contact with Jackie Caliman.