CIS 120 is designed to be a second semester introductory course that focuses on the foundations of programming. Whether this is the first computer science course you have taken at Penn or first formal computer science course at all, here is a compilation of common questions.
Please refer to this FAQ as your first line of help. More details about the course are available in the syllabus. Of course, if you have more specific questions, feel free to ask the course staff by either emailing your TA or posting a message via Ed.
- What is the homework submission policy?
- What is the late homework policy?
- What is the dropped homework policy?
- What should I do if I get an error upon submission?
- What does late submission without penalty mean?
- When and where are exams held?
- Will there be review sessions for the exams?
- Can I bring a cheat sheet to the exams?
- I have a conflict for the final; what should I do?
- I can't make or missed an exam because [insert reason here]!
- What's the exam grade/solution turnaround?
- How can I see my exam after I've received a grade?
- How can I request that my exam be regraded?
- What is recitation?
- What is the attendance policy for recitation?
- What is the policy for recitation assignments?
- What is the policy for recitation registration?
- What are the rules for acceptable behavior?
- What can I expect from the staff regarding academic integrity?
Office Hours and Ed
- What is Ed?
- What are some good guidelines for posting on Ed?
- When are office hours?
- I can't make it to office hours, but I have questions!
- What is considered to be an appropriate question?
- What is considered to be an inappropriate question?
- How can I have a more productive visit at office hours?
- Why should I have good coding style?
- What constitutes good style?
- How should I comment my code?
- How can I set up Eclipse to help me maintain good style?
- Is there a convenient reference for good coding style?
- What is the grade breakdown for the course?
- What should I do in case of a personal emergency?
- How well am I doing in the class?
- How should I debug my programs?
1. What is the homework submission policy?
- All homework assignments will be submitted online via the course website, with an assignment generally being due at midnight on that assignment’s due date
- Most homework assignments consist of an automatically graded portion based on code functionality (whether your code gives the correct answer on certain inputs) and a manually graded portion based on code style. Some assignments are completely manually graded.
- You are given multiple submissions per homework (as described on the web page for each assignment). Extra submissions can be used to fix any issues, stylistic or functional, that you may find in your code. For each submission past the allotted number of submissions, you will be penalized as specified by the assignment.
- Your final score for a given assignment is based taken from the highest automatically-assigned score for that assignment and a manually-assigned grade for the most recent submission.
- Note that any penalties incurred on a given assignment are applied to ALL scores for that assignment. Example: Say you make a total of 6 submissions of a given assignment and get 65, 70, 75, 72, and 85 on your first 5 submissions but an 82 on your 6th submission. You will receive a 80 on the assignment, since your highest raw score was an 85, to which a 5 point penalty for an extra submission was applied.
2. What is the late homework policy?
- Homework submissions will automatically close at the specified time (i.e. midnight). There is NO grace period; any submissions after the deadline will be late.
- See the course syllabus for information about the course late policy.
- NOTE: due to end of semester logistics, the last homework may have a HARD deadline; if that is the case, then no late submissions will be accepted!
3. What is the dropped homework policy?
- There are NO DROPPED HOMEWORK ASSIGNMENTS in CIS 120.
- Because no homework assignments are dropped, and homework is the largest portion of the course grade, skipping homework assignments is strongly discouraged!
4. What should I do if I get an error upon submission?
- While our servers generally work well, they will on occasion raise errors upon submission
- In all cases of error, it is prudent to document the error that you received through a screen capture of the error log. This will help us to appropriately alleviate the error, and will help dispel any possible doubt that you had a legimitate issue.
- Upon a submission error, you should contact a TA - either the TA on duty at office hours or, when no one is immediately available, your recitation TA, explaining the issue. Be sure to include any relevant information, such as the submission time and the error received, in your message. It is generally also prudent to attach a copy of the source code you attempted to submit with any error reports.
5. What does “late submission without penalty” mean?
- For some homework assignments, we may allow the option of “late submission without penalty,” meaning you may submit the assignment up to 48 hours after the given due date without incurring any penalty.
- The catch: While you may submit without penalty, there may not necessarily be any TA help, via office hours or Ed, during the period between the original due date and the late due date, as these due dates typically fall during periods where the course staff is collectively busy or out of town.
- In these situations, the late due date is the FINAL due date; no submissions after the late due date will be accepted!
6. When and where are exams held?
- Midterm dates and locations will be announced in class and posted on the course website at least a week prior to the exam. The final date should be announced shortly after the beginning of the semester.
- Some exams may have multiple locations; in these cases, your exam location will be based on the first letter of your last name. Check the course postings for that exam to determine your exam location.
7. Will there be review sessions for the exams?
- The TAs typically hold review sessions for exams (both midterms and the final) on an evening 1-2 days prior to the exam date.
- Review sessions will generally cover conceptual material that should be known for the exam, as well as guided review of practice material given on the course website.
- Questions are welcomed! Please bring whatever questions you have regarding the course material!
8. Can I bring a cheat sheet to the exams?
- This will be announced in class a few days prior to the exam.
9. I have a conflict for the final; what should I do?
- Once you are sure you will be enrolled in CIS 120, contact your professor regarding your conflict. He or she may ask you to email him or her again closer to the final date to schedule a makeup exam
- We follow the Provost’s rules governing final exams which strictly limit the situations in which make up exams are permissible.
10. I can’t make/missed an exam because [insert reason here]
- Please contact the course staff ASAP. We will deal with this on a case by case basis.
11. What’s the exam grade/solution turnaround?
- We try to get exam grades back within a few days.
- Please bear with us regarding grade turnaround. Exam grades, solutions and statistics will be released after all exams and makeups have been graded.
12. How can I see my exam after I’ve received a grade?
- You will be able to view your graded exam via gradescope.
13. How can I request that my exam be regraded
- You may submit an exam regrade request, via gradescope, within two weeks of receiving your exam grade.
- Please use regrade requests only when your exam has clearly not been graded according to the rubric.
- Your regrade request may result in points being added or subtracted from your exam score, and on any problem on the exam (not just the one that you requested a regrade).
14. What is recitation?
- Recitation is a weekly meeting of a small subset of the students enrolled in CIS 120, wherein a pair of TAs reviews course material and administers recitation assignments to reinforce course material.
- The TAs for your recitation are your liaisons for course logistics; they will be responsible for manual grading of your homework assignments, and will be your first line of contact regarding grades or other course questions.
15. What is the attendance policy for recitation?
- Attendance at recitation is required.
- You are permitted two absences from your recitation over the semester, after which you will be penalized.
- If you have a conflict with your recitation, you may opt to attend another recitation in a given week to avoid taking an absence, with permission of that recitation’s TAs. Please inform both your own TAs and the TAs whose recitation you will be attending, in order to ensure you are not penalized for an absence.
16. What is the policy for recitation assignments?
- In recitation, you will generally be given a recitation assignment to complete which will complement material covered in lecture and on that week’s homework.
- These assignments are graded for participation; you are not required to finish them. That being said, completion of the assignments is strongly encouraged, as they can prove extremely helpful in preparing you for the homework assignments. :)
17. What is the policy for recitation registration?
- Registration in a recitation is required as part of the course. If all available recitations conflict, you should email your professor.
- Changing recitations through Penn InTouch during the semester can be difficult. If you find your originally registered recitation is inconvenient, you should email your professor about switching sections.
18. What are the rules for acceptable behavior?
We encourage you to discuss the material and work together to understand it, but you must complete all homework assignments and exams yourself. For this reason, we have strict rules about what you can and cannot do. Naturally, the course also follows the standard Penn academic integrity code, so make sure that you are familiar with this as well. Copying of code from other students or outside resources, past or present, is STRICTLY FORBIDDEN. All code you submit must have been written by you.
We encourage you to:
- Discuss assignments, the readings, and lecture topics with one other
- Discuss general solutions to the homeworks
- It is fine to discuss the topics covered in the homeworks, to discuss approaches to problems, and to sketch out **general **solutions. However, you MUST write up the homework answers, solutions, and programs individually without sharing specific solutions, program code, etc.
- “High-level” questions about homework problems are acceptable; these entail questions about concepts learned in the course that may be relevant to the problem, as well as explanation of problem specifications.
- “Low-level” syntax questions are fine; these entail questions about how particular operations are done in the programming language of the given assignment (e.g. “Do I use = or == to do reference equality checks in OCaml?")
- If you made any notes or worked out something on a white board or paper with another person while you were discussing the homework, you shouldn’t use those notes while writing up your answer.
- 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.
You may not:
- Share your code with anyone, electronically or on paper, even after you are no longer in the course
- 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
- 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
- Use or consult code found on the internet for any of your assignments.
Use your best judgment.
- Protect both yourself and others. 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 friend’s or roommate’s computer, 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.
What does all that mean? Here’s an example: BAD A: I still can’t figure out this problem on HW06! How do you write checkboxes? B: Oh, I’m done already. Yea, that problem took forever. A: Wait. You’re done?! How did you do it?? Can I take a look at your code? B: Sure. turns computer screen around
OKAY A: I still can’t figure out this problem on HW06! How do you write checkboxes? B: Oh, I’m done already. Yea, that problem took forever. A: Wait. You’re done?! How did you do it?? Can I take a look at your code? B: Well, what are you stuck on? A: points to screen I don’t get this whole thing about listeners…. B: Oh! Yea, those things are weird. So think of it this way…. A: OK, I understand now - thanks! goes back to typing
If you have any questions or doubts as to what types of collaborations are allowed, please ask the instructor or your TA.
19. What can I expect from the staff regarding academic integrity?
- While we are not out to get you, we take academic integrity very seriously and will be watching out to make sure the above rules are enforced throughout the semester
- We use sophisticated automated tools to compare your homework submissions against submissions for the same assignment from past and present semesters. We will know if you copy someone else’s work!
- These programs are remarkably good at detecting plagiarism; changing variable names and simple code rearrangements don’t trick them.
- Modifying an existing program to defeat a cheat checker is just as hard as writing your own program from scratch.
- If we find anything suspect in your behavior or work, we will contact you promptly.
- Save yourself a headache, and us a heartbreak; DON’T CHEAT!
Office Hours and Ed
20. What is Ed?
- Ed is a wonderful forum-like site that we use for fielding course questions and posting class announcements!
- As a student, you can post a question to Ed, where it can be answered either by other students in the course, or by a member of the course staff
- If you are shy, or your issue is sensitive, fear not! Ed allows for you to post anonymously to your classmates, or to make posts viewable by instructors only!
- If you are enrolled in this class, you should automatically be signed up for Ed access within the first week of classes. If not, contact us!
21. What are some good guidelines for posting on Ed?
- Be polite! We have feelings too!
- Don’t be shy! We don’t bite! If you need further explanation after a response to your question, feel free to use the followup discussion feature of Ed to ask additional questions.
- If your question involves posting code or any information regarding answers to the assignment, please post it as a private post to instructors.
- Please use the Ed search feature prior to asking a question; you may find your question has already been asked and answered!
- When posting code, please use the Ed code feature; it does wonders for code readability!
- Before submitting a post to Ed, please reread it to make sure it makes sense! While we like to promptly address your questions, it can be very difficult if we’re not sure what you’re asking!
- If you are posting about problems with your code, please try to include specific information about what is wrong, along with what you’ve done so far to debug your program. We can’t do much with 200 lines of code and the declaration that your code simply “doesn’t work”!
- If you are posting a conceptual question, try to be as specific as you can regarding what you don’t understand; this will help us give you a more directed answer.
22. When are office hours?
- Office hours are posted on the office hours schedule (see the navigation bar of the course website).
- Office hours are generally held between noon and midnight on weekdays throughout the semester.
- While we attempt to keep a consistent schedule with office hours, please be mindful that your TAs are busy students like yourselves and may have to change their office hours due to other obligations. In this case, don’t panic! Ed, as you will come to learn, is a wonderful companion.
- Please note that office hours are NOT whenever you happen to see a TA out and about! While we are generally happy to help you out, the course staff have their own assignments and obligations. Please try to direct questions to Ed or TAs who are currently having office hours.
23. I can’t make it to office hours, but I have questions!
- Whenever you need a quick answer or cannot make office hours, Ed is your best friend!
- Feel free to post to Ed at any time of day. Bear in mind, you will not be guaranteed an answer in a timely manner if you are posting at 4 AM!
24. What is considered to be an appropriate question?
- Appropriate questions for TAs include conceptual questions, clarifications of homework specifications, and debugging assistance with particularly insidious bugs which your own attempts have failed to correct
- Good questions are as specific as reasonably possible! Furthermore, you should be able to follow up your questions with what understanding or progress you have for the problem at hand.
- Please try to debug on your own. We understand that it will be hard in the beginning and that you’ll need more help, but you should have a firm grasp of debugging by the end of the semester. You’ll save time not waiting on us to help you, and you’ll have a valuable skill for future CIS classes you take!
- Examples: “What are the invariants of a binary search tree?", “Should we return true or false if homework_function_xyz is given an empty list?", “Could you help me fix this problem? I’ve put five million print statements and written seventeen tests trying to debug this problem, but I still haven’t found the cause!”
25. What is considered to be an inappropriate question?
- Inappropriate questions for TAs include direct solicitation of homework solutions and undirected questions demonstrating no effort to fix the problem on your own
- You should take your best stab at a problem prior to asking a question about it; this will give us a jumping off point from which to help you!
- Examples: “Can you tell me how to write qinsert?", “My code doesn’t work. I haven’t tried debugging it yet. Can you help?", “I haven’t even tried doing homework_function_abc, but could you give me a hint or two?”
26. How can I have a more productive visit at office hours?
- Remember that a TA’s time at office hours is a limited and shared resource. While we’re willing to help, there will be many other students vying for attention, and you will ultimately be held responsible for completing your assignments even if we cannot give you our undivided attention!
- Start your homework early! Don’t wait until the last minute. You can expect office hours on the day homework is due to be packed.
- Have your code properly formatted! Bad code formatting makes it difficult for the TA to understand your code, which in turn makes it difficult for the TA to help you. Do not expect us to sift through spaghetti code to uncover underlying issues!
- Have a legitimate, specific question! Have a particular problem in mind and ask about it. It’s faster that way.
- Try debugging before we get to you! You are equipped with more tools than you know. Add print statements, add another test case. Poke around! You may already have the answer to your question.
- Put your name on the board before the last 30 min! If you put it on in the last 30 minutes of office hours, there is NO guarantee that the TA will get to you.
- Respond when we call on your name! Please tell us where you are if you’re in a different room. Try not to have your headphones on when it’s almost your turn. Thanks!
27. Why should I have good coding style?
- Good style has many benefits; to state the most apparent, well-styled code permits an easier understanding of the purpose and logic of a program, which can prove invaluable when you are attempting to develop or debug complex pieces of software
28. What constitutes good style?
- Good Formatting: How your code is laid out can vastly affect the readability of your code.
- Good Naming: How you name variables can vastly affect how readable your code is; the purpose of something called “max_element” is more obvious than something called “variable_xyz”.
- Good Logic: You should always strive to accomplish a given task in an elegant fashion; this helps to avoid visual and logical clutter, making your code easier to comprehend.
- Good Commenting: The purpose or methodology of a piece of code may not be immediately apparent; good commenting allows you to explain your work, making the code easier to understand.
- Good Testing: Good formatting means nothing if a piece of code doesn’t work. Good testing helps ensure your code works under all reasonable use cases. Furthermore, good testing ensures future changes to your code don’t ruin the core functionality!
- Along with the three things outlined above, consistency is key! In cases where personal preference dictates how you lay out a piece of code, choose one method and stick with it!
29. How should I comment my code?
- It is generally good practice to add a comment above any functions / methods providing a brief explanation of what the code is intended to do
- It is good practice to add comments above any lines of code whose purpose, despite attempts at good coding practice, is not immediately apparent. For example, you might add comments providing a clear explanation of what a particularly dense “if” statement is checking for.
- Note it is possible to go overboard with comments; you don’t necessarily have to comment every line of your program. If it’s obvious what a line of code does without any commentary from context, then it needs no comment. Note that good naming conventions can prove invaluable in making code self-documenting
30. How can I set up Eclipse to help me maintain good style?
- Eclipse allows for a few tricks that will make it easier to follow the style guidelines for this course. The following options are found on OS X by going to Eclipse -> Preferences -> General -> Editors -> Text Editors, or on Windows and Linux by going to Window -> Preferences -> … -> … -> …
- Insert Spaces for Tabs: Self-explanatory, this option prevents any weird formatting issues from arising when your code is viewed in different programs.
- Show Print Margin, Print Margin 80: These features, together, will show a grey line in the Eclipse text editor which shows where the 80 character point is in the document. This will help prevent you from exceeding the line limits stated in the style guidelines
- Show Line Numbers: Not directly related to style, but line numbers can aid navigation of your document as it begins to burst forth most bountifully with freshly-crafted code.
31. Is there a convenient reference for good coding style?
- For OCaml: Penn OCaml Style Guide
- For Java: Oracle Java Programming Conventions
32. What is the grade breakdown for the course?
- See the course syllabus.
32. What should I do in case of a personal emergency?
- Don’t panic! We are reasonable people, and will try our best to handle exceptional circumstances on a case-by-case basis.
- In cases of emergency or extenuating circumstance, please contact your TA as soon as possible before the homework deadline regarding your situation. Note that simply contacting us does NOT mean you will automatically be granted an extension.
- In cases where you must miss lecture, it is your responsibility to catch up on any missed course material.
34. How well am I doing in the class?
- Because the equivalence between points and letter grade is determined at the end of the semester, we cannot pinpoint your letter grade before the end of the course.
- If you are particularly concerned about your grade, please contact the professor or the TAs to discuss your situation. If you are having difficulties with the course material, feel free to contact the TAs or go to the tutoring center
35. How should I debug my programs?
- FIRST THINGS FIRST: IF YOU ARE DEALING WITH A COMPILATION ERROR, READ THE ERRORS ECLIPSE GIVES. If you hover over a red-underlined bit of code, Eclipse will explain what problem it has detected. This can give you a heads up on what issue you must fix with your code!
- While the TAs can help you in debugging, it is best to develop good debugging skills in order to prepare you for future programming work you may do; a few methods are below.
- Print statements: A venerable choice for budding programmers, you can track the state of your program by adding statements which print some value to the console at a particular point in the program’s execution. This can be used to keep track of the values your program is using, which may help find bugs.
- Test cases: You can often track down bugs by writing test cases which test specific inputs and attempt to narrow down what may be the cause of a bug
- Tracing by hand: In cases where you know the input that leads to errors, it can be a valuable exercise to take the input and explicitly step through your code’s operations on this input line-by-line; as long as you faithfully recreate your code’s actions on this input, you should eventually see where exactly things go wrong.
- Rubber Duck Debugging: named for a common muse used for this method, this involves verbally stating what your code should be doing (perhaps by reading through the assignment specifications) while simultaneously tracking what your code, as written, does. Often, you can uncover flaws in this way by realizing that your written logic deviates from the algorithm you intended to implement.
- Debugger: If you is willing to learn how a debugger is used, it can be a powerful tool; among other features, debuggers often allow the user to stop execution of a program at an arbitrary point and examine the values of the program’s declared variables at that point.