Spring 2019
CS Mentor Hours: M-F 4:00-7:00pm, CF 162/164
Syllabus and Course Website: https://facultyweb.cs.wwu.edu/~wehrwes/courses/csci141_19s
Intended for students majoring in computer science. Basic concepts of computer programming using an object oriented programming language. Topics covered: introduction to the development environment, introduction to algorithms, elements of a programming language, including data types, packages, control structures, procedures and functions, basic input and output, arrays and records, text files, strings, variant records. Algorithm development, problem solving and software engineering are emphasized. Programming is required in implementation of concepts. Lab.
On completion of this course students will demonstrate:
We will use the following free online interactive e-textbook as a reference:
How to Think like a Computer Scientist: Interactive Edition
Grades will be calculated as a weighted average of scores on the following course components, each of which is described in more detail below:
The standard letter grade ranges apply (i.e., 90–100% is an A, 80–90% is a B, and so on). The calculated raw percentages may be curved at the instructor’s discretion, but any such curve used will not lower anyone’s grade. “+” or “-” cutoffs will be decided at the instructor’s discretion. Students who demonstrate mastery of the material will get grades in the A range, and it is my goal to give as many A’s as possible.
Approximately 6 programming assignments will be given to provide hands-on practice with the programming concepts introduced in the course.
The midterm exam will be in-class on Friday, May 3rd and will test material covered through Monday, April 29th.
The final exam is scheduled for Monday, June 10th from 3:30pm to 5:30pm in our usual lecture classroom, MH 138. The final exam will be cumulative, but more emphasis will be placed on material covered since the midterm. Per the University Academic Policies, a student who fails to take a final examination without making prior arrangements acceptable to the instructor receives a failing grade for the course.
Several types of in-class assessment will be used during lectures. These low-stakes assessments provide both students and instructor with quick and actionable feedback about student learning, allowing both to make adjustments to teaching and learning strategies.
Labs will provide hands-on experience in topics related to the course with the support of a TA. To get full credit for a lab activity, you must both attend lab and hand in the deliverable by the deadline (typically Friday at 10pm the week that the lab takes place). Missing a lab or attending a lab section other than the one you are registered for requires permission of the instructor, so please contact me ahead of time in case of extenuating circumstances. Barring case-by-case exceptions, if you miss lab but submit the deliverable on time you will receive half credit (i.e., your score will be multiplied by 0.5). No late labs will be accepted.
The Schedule section of this page will be updated as the quarter progresses with topics, links to lecture slides, code examples, readings, and links to assignment and lab handouts.
We will use Canvas for announcements, grades, distribution and submission of assignments and labs. Lab and assignment writeups, lecture slides, readings, etc. will all be linked from both the course webpage and the corresponding assignment on Canvas.
It is your responsibility to make sure that you promptly become aware of Canvas Announcements as they are posted; Canvas should be configured to send you an email notification by default, but if you are unsure, please come see me in office hours.
Exams will be graded and returned to you via an online tool called Gradescope. You will receive an email when midterm grades are released inviting you to log into an account that has been created for you and set a password. Thereafter, you will access your graded exams by logging into your account on http://www.gradescope.com. If you have trouble accessing Gradescope after exam grades are released, please come talk to me in office hours.
This schedule is tentative and subject to change without notice. Slides, assignments, readings, etc. will be posted here throughout the quarter.
Date | Topics | Lab | Out | Due | Suggested Readings |
---|---|---|---|---|---|
4/2 | Introduction and logistics (slides) | No Lab | |||
4/4 | Computers, Algorithms, Pseudocode (slides, hello.py, mult.py) |
||||
4/8 | Types, Function calls, Variables (slides, types.py, print_input.py) |
Lab 1 | A1 | 2.1–2.4 | |
4/10 | Variables, Operators, Expressions (slides, L04.py) |
2.5–2.8 | |||
4/12 | Order of ops, Binary, Floating pt (slides, print_input_types.py) |
2.9–2.11 | |||
4/15 | Boolean logic (slides) |
Lab 2: badCode.py, faultyCode.py brokenCaluclator.py | A2 | A1 | 7.1–7.5 |
4/17 | Conditionals (slides, if.py, ifelse.py) |
7.4–7.7 | |||
4/19 | Conditionals, continued (slides, ifelse.py, sections.py, sections_elif.py, sections_refactored.py) |
7.7–7-8 | |||
4/22 | While loops (slides, balance1.py, balance2.py, count.py, never.py, input.py) |
Lab 3 | 8.3 | ||
4/24 | Modules, Objects, random, and Turtles (slides, checkpw.py, dice.py, nested.py) |
A3 | A2 | 4.1–4.3, 5.1–5.4 | |
4/26 | More turtle, For loops, range (slides, ranges.py, square_while.py, square_for.py) |
4.4–4.7, 8.2 | |||
4/29 | Functions 1 (slides, for_quirk.py, rectangle.py, rectangle_arg.py; sample midterm questions) |
Lab 4 | 6.1 | ||
5/1 | Midterm review slides | A3 | |||
5/3 | Midterm Exam (curve.py) | ||||
5/6 | Functions 2 (slides, hello_fn.py, multiline.py, ex1.py, add2.py) |
Lab 5 turtleshape_test.py | Lab5 Handout; 6.2, 6.3, 6.5–6.10 | ||
5/8 | Functions 3 (slides add2.py, rectangle_area.py, geometry.py, q2.py) |
A4 sierpinski.py | Chapter 6 | ||
5/10 | Functions 4 (slides, q16.py early_return.py, tuples_abcd.py, geometry.py) |
Chapter 6; 10.26–10.28 | |||
5/13 | Strings 1 (slides, vowels.py) | Lab 6 | 9.1–9.4, 9.6, 9.10–9.12 | ||
5/15 | Strings 2 (slides, worksheet.py) | 9.5, 9.7–9.9, 9.13–9.20 | |||
5/17 | String comparisons; Lists 1 slides | A4 | 9.8, 10.1–10.7 | ||
5/20 | Lists 2; Mutability (slides, q20.py, bale.py) | Lab 7, lottery.py | 10.7–10.11, 10.16 | ||
5/22 | Lists 3; Dictionaries (slides, slice_assign.py, q21.py, weather.py) |
A5, skeleton, train, test | 10.12–10.14, 10.17–10.25; 12.1–12.3 | ||
5/20 | Lists and Dictionaries (slides, z.py, worksheet.py) | 12.3–12.4; Chapter 10 | |||
5/27 | Memorial Day: No Class | No lab | |||
5/29 | Lists and Dictionaries Wrap-up (slides, q23.py, snap.py) |
||||
5/31 | File I/O (slides dict_iter.py, split.py, file_read.py, file_read_write.py, test.txt) |
Chapter 11 | |||
6/3 | Evals; Quiz (slides, q25.py) | Lab 8, plot_earthquakes.py, earthquakes.csv, earth.png | |||
6/5 | Review and advanced topics (slides, Why -13 // 4 == -4) (sample_final_qs.txt, answers.txt) |
||||
6/7 | Review and advanced topics | ||||
6/10 | Final Exam 3:30–5:30 |
It is expected that everyone will promote a friendly, supportive, and respectful environment in the classroom, labs, and project groups. Everyone’s participation will be equally welcomed and valued.
Lecture attendance is not tracked explicitly, but no credit will be given for missed in-class assessments activities. The lowest 3 in-class assessments will be dropped from your grade. Lab attendance is required; if you finish the lab before the end of the lab period, you may leave early after showing your work to the TA.
You have three “slip days” that you may use at your discretion to submit programming assignments late. Slip days apply only to programming assignments and can not be applied to any other deadline. You may use slip days one at a time or together - for example, you might submit each of three assignments one day late, or submit one assignment three days late. A slip day moves the deadline by exactly 24 hours from the original deadline; if you go beyond this, you will need to use a second slip day, if available.
After your slip days are exhausted, a penalty of 10% * floor(hours_late/24 + 1) - that is, 10% per day late, will be applied.
Your programs will be graded on correctness, clarity, and efficiency (in that order).
A correct program is one that always produces the correct output for a given input. Also, a correct program does not produce unintended side-effects. The most effective way to ensure that your program is correct is to test, test, test. Test each component as you introduce it; once you are confident that a component works you can use it in other routines. Try to break your program in testing, and if you succeed, locate the bug and fix it. The better you test your program, the more likely it is to be correct - the more likely it is to be correct, the more likely you’ll earn a good score. Most of your grade will depend on the correctness of your code.
The easier it is to read and maintain your code, the easier it is to locate and remove bugs. Your program should be well organized, appropriately commented, and easy to maintain. To have a well-organized program, design your program thoughtfully and modularly. Think before you code: hacking away blindly leads to ugly, difficult-to-read code. If you do hack away, producing a functional but ugly wall of code, try to clean it up a bit. Make sure that your cleaning does not introduce new bugs.
As for comments, please follow these simple guidelines proposed by Emeritus Professor Osborne:
Your code should be efficient, in the sense that the programs you write in this class should run in a few seconds or less. If you continue on in CS, the definition of and standards for efficiency will get more rigorous; for now, just make sure your programs aren’t doing a lot of unnecessary work.
Individual programming assignments are to be completed independently. Students are welcome to discuss assignments with each other on a conceptual level, but each student should be writing their code independently and without direct help from fellow students. Sharing your code with others or looking at someone else’s code is an explicit violation of this collaboration policy. To make sure you are collaborating appropriately, follow these two rules:
Automated tools will be used to check your code for plagiarism at the push of a button. They are not fooled by tricks such as changing variable naming and whitespace: in fact, hiding plagiarism is harder than doing the assignment.
For pair programming assignments, the above policy applies to any collaborations with people outside your group. In addition, the following pair programming best practices must be followed:
Please review the University policies outlined at http://syllabi.wwu.edu regarding: