jump down this page to: schedule | final grades | assignment grades | exams | late policy | academic dishonesty | compilers | style conventions

Instructor
Dave Harden
Email: harden.classes@gmail.com
Office Hours: W 1:15 - 2:15pm in room 2923.
In addition, I am available by email and discussion posts.
Response Times: I almost always respond to emails and discussion posts by the end of the following school day, always by the day after that.
Please use the online class discussions for all questions whenever possible. For private questions that are not appropriate for the class discussion, email me at harden.classes@gmail.com and include "CS 10C" in the subject. Please don't use Canvas messaging (or "inbox").
Course Tutor
We have a volunteer course tutor for our class! His name is Elliot Barlas (elliotbarlas@gmail.com) and he is a local software engineer and a former SRJC student. He tutors for this class exclusively, so he is well-acquainted with the class assignments, and I have received excellent feedback from students who have been tutored by him in the past. He is available (remotely) by appointment. Just send an email to elliotbarlas@gmail.com to set up a time. Please take advantage of this valuable resource!
You can read more about Elliot in this Argus Courier article about a free Petaluma-themed mobile game he wrote in C++ in his hobby programming time:
https://www.petaluma360.com/article/news/free-trippin-on-tubs-game/
Three Most Important Announcements!
You must post an introduction in the class "introductions" discussion by Tuesday, Jan 21, or I am required to drop you from the class. When you begin working your way through the modules, you'll see that this is the first task for week 1.
Absolutely no assignments will be accepted for any reason after Wednesday, May 14.
In the rare event that I grant an extension (due to prolonged illness, for example), it will always be via email. If you do not have an email from me stating clearly that I am giving you an extension, you do not have an extension. I do not give extensions verbally. Also, it is imperative that you read the Extensions Policy carefully!
Course Organization
The course is organized around the modules page. If you simply make your way through each item in the module each week, you will complete all of the required (and optional) tasks. In fact, if you see a task that is not list in a module, then you should not consider it to be part of the course.
Textbook
We're using an interactive etextbook published by zyBooks. The first time you click on a link in Canvas that leads to the zyBook, you will need to subscribe to the text for $89. (You can also purchase an access code in the bookstore, if you prefer.) I think you're going to find that this is a great way to learn computer programming!
Schedule
Assignments are due at 11:59pm on the date indicated in this schedule. Be sure to check the late policy for more information.
Module # |
Topics |
Lesson |
Text Reading |
Assignments |
Suggested Start Date |
Module Due Date |
1 |
Intro/Templates/Iterators |
19 |
Chapter 1 |
Module 1 Reading
Projects 24.1 - 24.2
Chapter 1 Test
|
Monday, Jan 13 |
Tuesday, Jan 21 |
2 |
Containers |
N/A |
Chapter 2 |
Module 2 Reading
Projects 27.1 - 27.5
Chapter 2 Test
|
Tuesday, Jan 21 |
Monday, Jan 27 |
3 |
Array-Based Sets |
N/A |
N/A |
Projects 28.1 - 28.2
|
Monday, Jan 27 |
Monday, Feb 3 |
4 |
Advanced Recursion |
N/A |
N/A |
Project 29.1
|
Monday, Feb 3 |
Monday, Feb 10 |
5 |
Searching/Sorting/Analysis |
24 |
Chapters 3, 4 |
Module 5 Reading
Project 30.1
Chapters 3&4 Test
|
Monday, Feb 10 |
Monday, Feb 17 |
6 |
Link-Based Sets |
20 |
Chapter 5.1 - 5.6 |
Module 6 Reading
Projects 31.1 - 31.2
|
Monday, Feb 17 |
Monday, Feb 24 |
7 |
Lists 1 |
20 |
Chapter 5.7 - 5.16 |
Module 7 Reading
Project 26.1
|
Monday, Feb 24 |
Monday, Mar 3 |
8 |
Lists 2 |
20 |
N/A |
Project 26.2
Chapter 5 Test
|
Monday, Mar 3 |
Monday, Mar 10 |
9 |
Stacks |
21 |
Chapter 6.1 - 6.5 |
Module 9 Reading
Projects 32.1 - 32.3
|
Monday, Mar 10 |
Monday, Mar 24 |
10 |
Queues |
N/A |
Chapter 6.6 - 6.14 |
Module 10 Reading
Projects 33.1 - 33.3
Chapter 6 Test
|
Monday, Mar 24 |
Tuesday, Apr 1 |
11 |
Hash Tables |
N/A |
Chapter 7 |
Module 11 Reading
Project 34.1
Chapter 7 Test
|
Tuesday, Apr 1 |
Monday, Apr 7 |
12 |
Trees |
23 |
Chapter 8 |
Module 12 Reading
Project 35.1
Chapter 8 Test
|
Monday, Apr 7 |
Monday, Apr 21 |
13 |
Balanced Trees |
N/A |
Chapter 9 |
Module 13 Reading
Project 36.1
Chapter 9 Test
|
Monday, Apr 21 |
Monday, Apr 28 |
14 |
Heaps |
N/A |
Chapter 10 |
Module 14 Reading
Project 37.1 - 37.3
Chapter 10 Test
|
Monday, Apr 28 |
Monday, May 5 |
15 |
Graphs |
N/A |
Chapter 11 |
Module 15 Reading
|
Monday, May 5 |
Monday, May 12 |
Final |
|
|
Chapter 11 Only |
|
Monday, May 19 |
Monday, May 19 |
Final Grades
Your final score will be made up of the following components:

Component | Points Each | Points Total |
Discussions (15) | 5 | 75 |
Assignments (15) | varies
| 725 |
Tests (10) | 20 | 200 |
total | | 1000 |
Grades will be assigned as follows: 900 for an "A", 800 for a "B", 700 for a "C", and 600 for a "D". Grades of + or - are not given.
Discussions (75 points)
You will be required to make one substantive post in a discussion each week. Each discussion is worth 5 points. To be confident that you'll get the 5 points, you should typically expect your post to be around 30 words or more. Posts with fewer words can, of course, be considered substantive, especially if it is a serious question about the content or a serious response to another student's question about the content.
Assignments (725 points)
There will be three types of assignments:
1. Reading Assignments (160 points)
Most modules will include a Reading Assignment that is graded automatically by zyBooks.
2. Non-Programming Projects (70 points)
These are projects that you will either write out by hand or complete using an application such as a word processor or spreadsheet.
3. Programming Projects (495 points)
Programming Projects will be scored automatically in zyBooks. Note that it is very common for incorrect code to run fine on one compiler and then fail on another. Your code must run correctly on every compiler. Don't be surprised if your code works for you but doesn't pass all of the tests the first time you submit to the grading system.
Your Programming Projects will also be checked manually to ensure that all requirements have been met and that the Style Conventions have been adhered to. You should practice the Style Conventions on all of your Programming Projects.
Programming Projects will be scored according to the percentages in the following table. Note that the number in the first column corresponds to the number in the Style Conventions section, which appears later in this document.

1 | Comments | 20% |
2 | Appearance (e.g. Whitespace, Wraparound) | 5% |
3 | Identifier Names | 10% |
4 | Decomposition | 20% |
5 | Indentation | 10% |
6 | Simple Code/No Repeated Code | 25% |
7 | Miscellaneous | 10% |
Program submissions that use concepts that have not been covered in class may receive a score of 0.
Tests (200 points)
There will be a test for each chapter of the text, except that chapters 3 and 4 will be combined, for a total of 10 tests. All are based on the textbook reading assignments. All are taken online. Due dates for tests can be found on the Canvas modules page. They are always on the day after the corresponding assignment is due (usually Tuesday), and you can take each test at any time of your choosing during the day on which it is scheduled. They are due at 11:59pm. Once you start, each test must be completed within one hour, so ensure that you will not be interrupted once you begin. All tests are multiple choice.
You will take the tests on the honor code. The tests are available for an entire day for your convenience, but the validity of the tests relies heavily on your academic integrity. Don't take advantage of the flexibility by sharing questions with students who have not taken the test.
You are required to simulate a class environment when you take the tests. The tests are open book and open notes and even open compiler, but you cannot receive any help from another person. The rules are summarized below. Email me if you have any questions:
- Allowed: Textbook
- Allowed: Notes
- Allowed: Past assignments
- Allowed: Compiling your answers
- Not Allowed: Browsing non-class websites
- Not Allowed: Accepting assistance from another person.
- Not Allowed: Sharing questions with other students after the test.
Late Policy
This late policy is for Reading Assignments, Projects, and Discussions only. Late tests are not accepted.
Assignments are due at 11:59pm on the date indicated in the schedule. However, assignments and discussions may be submitted up to one week late with no penalty. This is the "final deadline". There is no limit to the number of times you may use this grace period. (Please don't email me to ask me if I really mean this. I do.) This does not mean that the due date is extended! For example, if your assignment is not done by the original due date, and you get severely ill between the due date and the final deadline, so that you cannot complete your assignment by the final deadline, it will be considered late. In addition, failing to complete projects by the original due date will put you behind in the class, and may delay the grading of your assignment significantly. You should make every effort to complete the assignment by the original due date.
For technical reasons, the due dates shown in zyBooks are the final deadlines rather than the due dates.
Beyond the final deadline, assignments will be accepted until 2 weeks after the original due date (except that no assignments will be accepted after Wednesday, May 14). They will be considered late and will receive a 50% deduction, with no exceptions. Assignments are not accepted more than 2 weeks late.
In order to get credit for an assignment that is submitted after the "final deadline" you must submit it in zyBooks and then email me to let me know.
Note that nothing in this Late Policy is intended to imply that you may resubmit an assignment once it has been graded.
To repeat: absolutely no assignments will be accepted for any reason after Wednesday, May 14.
About Extensions
The late policy in this class is already extremely generous.
Under extreme circumstances (e.g., extended serious illness) I may grant an extension as an exception to the above late policy. In this case, you must proactively request the specific extension and receive notice of the extension in an email. Otherwise it is not valid. Requests for extensions will not be granted if you wait more than a couple of weeks after the due date.
Due to the already generous late policy, extensions will not be granted for problems such as brief illnesses, family or personal issues, or emotional distress that is not accompanied by a doctor's note. If these problems cause you to lose too many points, you should consider withdrawing from the class.
Academic Dishonesty
All work that you submit must be your own work.
You are free to work together with and get help from your classmates. This should be limited to discussing the assignment. It should not, for example, require you to view each others' code (with one exception noted below). You are free to research topics online (although I don't advise this), provided that the work you submit is completely your own. In this class, these guidelines will be enforced as follows:
- Any such collaboration must be cited near the top of the documentation for your submitted code.
- Any such collaboration must not result in code that is so similar to another student's code or to code found online that I am able to detect the collaboration.
I understand that point #2 may be hard for you to determine. Therefore, (1) If you are not sure whether your collaboration crosses this line, PLEASE CHECK WITH ME. Also, (2) you will receive one warning. There will be no consequence for a first violation of this policy, provided you have cited the collaboration.
I suggest that in order to avoid any questions, you get all of the information you need for the course from the text and lessons. If you need help, ask in the discussion, email me, or get help from official tutors from the college.
Further guidelines for using online help:
You should not use even one line of code that you find online, even if you modify it. You may use websites for reference purposes (for example: how does a particular language feature work?). But you should not get information specifically related to a problem you are trying to solve (for example: what's an algorithm for reducing a fraction?). In particular, Don't ask for help from online forums. They will almost invariably do the problem for you, or give you bad information.
Examples of specific actions that violate this policy:
- Using chegg.com or coursehero.com or essaytaste.com or any AI for any reason
- Using an online tutor
- Looking at another student's code
- Showing another student your code
- Viewing or copying code online that is related to a course assignment
Exceptions:
- You can look at another student's code onlyif it is in order to help that student. You must be confident that you won't use any of the other student's code in your own work.
- You can show another student your code only if you need help from that student. You must be confident that that student will not use any of your code in their work.
Consequences
A first violation of this policy (with no citation, as described above) will result in a zero on the assignment and the submission of an Academic Dishonesty Report.
If you have received a warning, then a subsequent violation of this policy will result in a zero on the assignment and the submission of an Academic Dishonesty Report, even if there is a citation.
A subsequent violation following a violation that resulted in a zero on an assignment will result in an "F" in the class.
Compilers:
You will need to have a C++ compiler installed on your computer. This course requires that the assignments you turn in compile and run correctly with every ANSI/ISO standard C++ compiler. You are free to use any C++ compiler you choose; however, I strongly recommend Visual Studio if you are working in Windows and XCode if you are working on a Mac. If you choose to use a different compiler, it is unlikely that I will be able to help you with it if you get stuck. There are tutorials in the "Getting Started Tutorials" module in Canvas to help you get started with the two recommended compilers.
Course Description and Student Learning Outcomes
Application of software engineering techniques to the design and development of large programs; data abstraction and structures and associated algorithms.
Upon completion, students will be able to
- Write programs in C++ that use arrays, linked lists, stacks, queues, hash tables, and recursion.
- Explain how object-oriented programming uses abstraction to increase reusability of software.
- Summarize the differences between programming paradigms.
Style Conventions
[How To Get Good Grades On Your Programs]
In the real world, programmers usually work in teams and often the company that they work for has very precise rules for what kind of style to use when writing programs. For this reason, and also to encourage good programming style, we will be adopting the following style conventions for this class. This is not to say that these rules represent the only good style for writing computer programs (although in most cases they do). After you finish CS 10C, you may decide that you prefer a different style than what is required here. However, in order to get good grades on your programming projects in this class, you must follow these guidelines.
Note: By this point you all have a lot of programming experience and have developed your own styles. I will be flexible about most of the guidelines below if your approach is reasonable. Each Style Convention below is marked with a number indicating one of the following:
- critical. You may lose points if you fail to implement this.
- Not important that you do it exactly this way, but you must have some way to accomplish the same thing.
- If you disagree, you can ignore.
If you're not sure what is required exactly, please ask!
- Documentation:
A. Initial File Comment [2]: Your programs should be well-documented. Each program should begin with an initial file comment. This comment should start by indicating your name, class, date, instructor, name of file, etc. Next it should describe in detail what the program does and how the code works. Any input expected from the user and any output produced by the program should be described in detail.
Important local variables should be commented at their declaration. Aside from this, in most cases it should not be necessary to place comments in the body of a function. This usually clutters up your code and ends up making the function more difficult to read. If you find yourself needing to explain something in the middle of a function, perhaps you should look for a clearer way to write it!
B. General Advice [1]: Your comments should be directed toward a reader who is an expert C++ programmer. You should not explain features of the language!
C. Function Comments (Global Functions)[2]: Just above each of your global function definitions you must provide a comment describing what the function does. A simple function might have a 15 word comment, while a more complex function should have a comment of at least 50 words. Make sure to explain the role of each parameter in your function comments, and refer to them by name. Use of pre/post conditions is encouraged.
D.Comments in Classes: If this is your first time using the following guidelines for writing comments in a class, try your best to follow the instructions below, but don't worry too much about getting everything just right. You'll get full credit if it looks like you gave it your best shot.
D.1. Header File [2]: In the case of a class, the header file should begin with a (typically) very large header comment. This comment should include a general description of the class (so a client programmer can tell right away whether she wants to use it), followed by a listing of all of the prototypes of public members, each with pre and post conditions. Note that this list of prototypes is still part of the comment. You will have to list the prototypes again in the code below this header comment! You are required to use pre/post conditions to document your public member functions. Do not include any comments regarding the implementation details in the header file! This very large comment will then be followed by the header file code (e.g. the class declaration), with no comments.
More info about pre/post conditions: page 1 | page 2
D.2. Implementation File [2]: In the implementation file you should start with a class invariant. (I don't expect you to have prior knowledge of what a class invariant is. The description that follows should suffice.) The class invariant will include a description of the private data members and how they are used, as well as a statement of anything that you guarantee will always be true for class objects (for example: "fraction objects will always be stored in lowest terms"). Aside from the class invariant, the only comments you will need in your implementation file are comments on the implementation of complex functions, and comments on private functions (which do not get comments in the header file).
Here is an outline of how this will look.
-
Appearance:
A. General [2]: Use lots of whitespace (blank lines and spaces) to separate the different parts of your program!! When I look at your program my first impression should not be a page crammed with code. Get rid of wraparound. Put a blank line between your declarations and your statements. Put a space before and after each operator so that instead of
cout<<"Hello"<<x<<"my name is"<<endl<<bob;
you write
cout << "Hello" << x << "my name is" << endl << bob;
Make sure your lines aren't too long, no more than 80 or 90 characters.
B. With Functions [2]: Put at least 6 blank lines between function definitions.
-
Identifier Names:
A. General [1]: Choose your identifier names very carefully. Variable names should precisely represent what the variable is storing. Do not use abbreviations unless you have seen the abbreviation used in a lesson. Don't use one letter variable names except, perhaps, in for loops.
B. With Functions [1]: Choose your function names so that as much as possible your program reads like English and the names describe precisely what the function does. Void function names should start with an action word (readString, getData, etc.).
-
Decomposition [2]:
Any time there is a sequence of statements in your program that performs a specific, nameable sub-task, you should consider making that sequence of statements into a function. A nice length for functions is about 10 lines, although in CS 10C there will be occasions on which you'll have functions significantly longer. Consider making complex functions (for example, nested loops) even shorter. A goal: when you are done with your program, I ought to be able to look at any particular function and have a general understanding of what is does and how just at a glance.
-
Indentation [2]:
Indents must be exactly 4 spaces.
You may follow the indentation scheme used in the textbook or you may use the scheme used in the lectures. No others. For example, every statement must appear on a line by itself, every close curly brace must appear as the first (or only) item on a line, and every open curly brace must appear as the last (or only) item on a line.
- Simple Code/No Repeated Code [1]:
Make sure that your code is as simple as possible and that there is no unnecessary repeated code.
-
Miscellaneous:
[1] In most cases no numbers other than 1 or 0 should appear in your program. Other numbers should usually be declared as global constants.
Do not use any global variables. In some cases violating this guideline can result in a 0 on an assignment.
-
[3] Do not use "break" (except in a switch statement), "return" (except in a value-returning function), "exit", or "continue".
-
[1] Use pass by value unless you have a good reason to pass by reference. Always pass objects by reference. When passing an object by reference, use the "const" modifier when the value of the parameter should not be modified.
-
[3] Don't mix up statements and expressions. For example, count++ should not be used as an expression, but as a statement.
-
[3] You must use a value-returning function if (a) there is exactly one value being communicated to the calling function, and (b) there is no input or output occurring in the function.
[3] Use a for loop for counter controlled loops. Do not use a for loop for any other kind of loop.
[3] Never use the fact that C++ implements true and false using the int values 1 and 0. For example, never use 1 or 0 in the place of true or false.
[1] Use only standard C++.
[3] Don't use typedef except to declare a type in a class declaration so that the client can use it.
[1] Never use goto.
[3] Never use the ?: operator.
[3] Don't use the preprocessor except for #include and for making sure that a header file is not multiply included (#define, #ifndef, and #endif).
[3] Use initializor lists only in the context of inheritance.
[3] The characters "== true" or "== false" should never occur in your code.
[3] You should never have
if (x) {
return true;
} else {
return false;
}
or
if (x) {
return true;
}
return false;
in your code (where x is any expression). These can be replaced with simply
return x;
[2] Don't define member functions inside a class declaration.
[1] Do not use a floating point variable to store a quantity that will always be an integer.
[1] If a file includes a main() function, it must be the first function in the file.
[1] Don't use the "auto" keyword. There's nothing wrong with using it, but for our purposes in learning the language, we need to practice working out the complete type that goes in the code.