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 four lectures a week, MWFR 10-11 in Towne 321.
Recitation will follow every day, from 11-12. Attendance is
required for both lecture and recitation.
Slides will generally be posted on the lectures page before or
shortly after class. Lecutres are not recorded during the Summer term.
Grading
The approximate grade breakdown for the course is:
- Homeworks: 40%
- Midterm: 20%
- Final: 30%
- Recitation: 10%
- Staff Discretion: Adjustment for participation, etc.
An apparent serious lack of effort may be grounds for failure in
the course. If you find yourselves in any of the situations
below, you should meet with the instructor promptly to
discuss your situation:
- Numerous missed assignments or substntially blank assignments.
- Missed midterm or final exam. Be prepared to provide
documentation of a serious emergency to justify any unexcused exam
absence.
- Copied assignment (see the collaboration policy below). If you
believe you may have violated the collaboration policy, you are
encouraged to explain what happened to the instructor. Even if
your actions constitute a serious violation, the sanctions are
likely to be considerably less if you turn yourself in.
The course is graded on a curve, with individual adjustments as
needed:
- Each component of your grade is curved independently. The curves
are noramlized, then combined to get a global ranking. Exam
averages tend to be relatively low, reflecting the nature of the
exams; homework averages tend to be relatively high, reflecting the
effort that many students put into them.
- The median and standard deviation for each exam will be posted,
and approximate letter-grade guidance for the midterm (but
not the final) will be posted to help you evaluate your own learning
and performance. The median and standard deviation for the
homework assignments will not be given out.
- 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. Counting points will not help
you get more points, only distract from the substance.
- 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.
Re-grades
You may request a re-grade for homeworks up to three
days 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 at 9pm.
- Unless the homework states otherwise, there is a three
hour grace period beyond the deadline, when you can still
submit the assignment. You will not receive extra credit if you
submit during the grace period, and you will not get help from the
course staff (via office hours, piazza, or e-mail) during the grace
period.
- Late submissions beyond the grace period will not be
accepted. Extensions will be granted only in very exceptional
circumstances. Be aware that the Summer term is very fast paced,
and it will be almost impossible to catch up any significant delay.
Although we will work with you to find a solution, a week-long
illness that could be handled with an extension during the year may
require an incomplete or withdrawing from the course in Summer.
- Homework must be submitted through the online submission system.
All deadlines are automatically enforced. If your homework
is late, you will not be able to submit.
- You may not use late days or the grace period together with
an extension. This rule is enforced by the submission system.
- If you have trouble with the submission system, e-mail your code
to your TAs before the deadline. We will normally give you
an extension to resubmit online once. Submit your next
assignment early and seek help if you still have problems. (You can
always resubmit later on.) We will not normally give you a second
such extension unless you have sought help resolving the
problem.
- 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.
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:
- 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.
- 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.
- 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;
- Post your code anywhere that is publicly accessible, such
as GitHub (making your code widely available, even
unintentionally, is a very serious violation of the course
policy);
- 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 without warning. 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).
- Do not put a copy of your code on a friends' or roommates'
computers, even temporarily and even if you absolutely trust
them. Do not access your code via a web browser or online
service such as DropBox from anyone else's computer. If you
are not able to work on your own computer or on a lab
computer, keep your code on a USB key. The temptation
of code left in the browser cache or recycle bin has gotten
the better of more than one student.
- 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 or receiving 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.