CS 110B Programming Fundamentals: C++
Course Syllabus
jump down this page to: schedule | final grades | assignment grades | late policy | collaboration | compilers | style conventions
Instructor
Dave Harden
Email: harden.classes@gmail.com
Office Hours: Wednesday 1:15 - 2:15 here: Dave's Zoom Room
Response Times: I almost always respond to emails and discussion posts within 24 weekday hours, always within 48 weekday hours.
Please use the class discussions for all questions whenever possible. For private questions that are not appropriate for the class discussion, email me. Do not attempt to contact me using the Canvas messaging system (or "inbox"). Please include "CS 110B" in the subject when you email me!!
Three Most Important Announcements!
You must post an introduction in the "introductions" topic of the class forum 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 7.
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!
Am I in the Right Class?
There is no prerequisite for this class, but I strongly recommend CS 10 or CS 110A (or an equivalent). In this class we cover all of the programming topics from CS 10/110A in 4 weeks (2 weeks during summer). This class is not primarily intended for students with no programming experience. You're welcome to give it a try, of course. I just want to make sure you know what you are getting into.
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 to C++ | 1, 2, 3 | Chapters 1 - 4 | Module 1 Reading Project 4.5 |
Monday, Jan 13 | Tuesday, Jan 21 |
| 2 | Loops | 4, 5 | Chapters 5 - 7 | Module 2 Reading Project 7.4 |
Tuesday, Jan 21 | Monday, Jan 27 |
| 3 | User-Defined Functions | 6, 7, 8 | Chapters 8, 9, 12 | Module 3 Reading Project 12.2 |
Monday, Jan 27 | Monday, Feb 3 |
| 4 | Arrays | 9 | Chapter 13 | Module 4 Reading Project 13.1 |
Monday, Feb 3 | Monday, Feb 10 |
| 5 | Objects and Classes 1 | 15.1 - 15.6 | Chapter 14 | Module 5 Reading Project 14.1 |
Monday, Feb 10 | Tuesday, Feb 18 |
| 6 | Objects and Classes 2 | 15.7 - 15.9 | Chapter 15 | Module 6 Reading Project 15.1 |
Tuesday, Feb 18 | Monday, Feb 24 |
| 7 | Pointers | 12 | Chapter 16 | Module 7 Reading Projects 16.1 - 16.2 |
Monday, Feb 24 | Monday, Mar 3 |
| 8 | Chars and C-Strings | None | Chapter 17 | Module 8 Reading Project 17.1 |
Monday, Mar 3 | Monday, Mar 10 |
| 9 | Streams | None | Chapter 18 | Module 9 Reading (No Project) |
Monday, Mar 10 | Monday, Mar 17 |
| Midterm | Chapters 1 - 17 | Monday, Mar 17 | Monday, Mar 17 | |||
| 10 | Objects and Classes 3 | 16 | Chapter 19 | Module 10 Reading Project 19.1 |
Monday, Mar 17 | Monday, Mar 24 |
| 11 | Classes with DM 1 | 17 | Chapter 20 | Module 11 Reading Project 20.1 |
Monday, Mar 24 | Monday, Apr 7 |
| 12 | Classes with DM 2 | 17 | Chapter 21 | Project 21.1 (No Reading) |
Monday, Apr 7 | Monday, Apr 14 |
| 13 | Inheritance | 18 | Chapter 22, 23 | Module 13 Reading part 1 Project 22.1 Module 13 Reading part 2 Project 23.1 |
Monday, Apr 14 | Monday, Apr 21 |
| 14 | Templates, etc. | 19 | Chapter 24 | Module 14 Reading (No Project) |
Monday, Apr 21 | Monday, Apr 28 |
| 15 | Recursion | 22 | Chapter 25 | Module 15 Reading (No Project) |
Monday, Apr 28 | Monday, May 5 |
| Final | Chapters 18 - 25 | Wednesday, May 14 | Wednesday, May 14 |
Final Grades
Your final score will be made up of the following components.
| Component | Points Each | Points Total |
| Assignments | varies | 725 |
| Discussions (15) | 5 | 75 |
| Midterm | 100 | 100 |
| Final | 100 | 100 |
| total | 1000 |
Grades will be assigned as follows: 900 points for an "A", 800 for a "B", 700 for a "C", and 600 for a "D". Grades of + or - are rare and at the instructor's discretion.
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 are two types of assignments:
1. Reading Assignments
Each module (except Module 12) will include a Reading Assignment that is graded automatically by zyBooks.
2. Projects
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.
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.
Projects will be scored according to the percentages in the following table. Note that the number in the first column corresponds to the item number in the Style Conventions section, which appears later in this document.
| 1 | Comments | 20% |
| 2 | Appearance (e.g. Whitespace, Wraparound) | 10% |
| 3 | Identifier Names | 10% |
| 4 | Decomposition | 20% |
| 5 | Indentation | 10% |
| 6 | Simple Code/No Repeated Code | 20% |
| 7 | Miscellaneous | 10% |
Project submissions that use concepts that have not been covered in class may receive a score of 0.
Exams (200 points)
There will be a midterm and a final. Both rely heavily on the textbook reading assignments. Both are taken online, and you can take each exam at any time of your choosing during the day on which it is scheduled (see the schedule). They are due at 11:59pm. Once you start, each exam must be completed within one hour, so ensure that you will not be interrupted once you begin. Both exams are multiple choice. The coverage of each exam is given in the schedule.
You will take the exams 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 exams. The exams 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 assignments and discussions only. Late exams 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 how many 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 7). 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 partial 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 7.
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 any 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 Week 1 Module in Canvas to help you get started with the two recommended compilers.
Student Learning Outcomes
After successful completion of this course, students will be able to:
- Outcome 1: Create programs which use standard C++ language features, including functions, arrays, arrays of arrays, pointers, pointer arithmetic, dynamic memory allocation, and structured data (structs).
- Outcome 2: Design and implement an abstract data type using a class with member variables, member functions, constructors, and a destructor.
- Outcome 3: Design and implement modular programs, created in appropriate .h and .cpp files, that use multiple classes with inheritance relationships, friend functions, friend classes, and operator overloading, using modern C++ language features and STL vectors and iterators where appropriate.
Accommodations Statement
Students with disabilities who need accommodations are encouraged to contact me. Disabled Students Programs and Services (DSPS) is available to facilitate the reasonable accommodation process. The DSPS office is located in the Rosenberg Library, Room 323 and can be reached at (415) 452-5481.
Anti-Discrimination Statement
The San Francisco Community College District is committed to the principles of equal opportunity, and the prevention of discrimination and harassment in any program or activity of the District on the basis of race, color, ancestry, national origin, ethnic group identification, religion, age, gender, gender identity, marital status, domestic partner status, sexual orientation, disability or AIDS/HIV status, medical conditions, or status as Vietnam-era veteran, or on the basis of these perceived characteristics, or based on association with a person or group with one or more of these actual or perceived characteristics.
If you believe you have been subject to discrimination, please contact Mildred Otis, Title 5/EEO/ADA/Title IX Compliance Officer, at motis@ccsf.edu.
Equity/Diversity/Inclusion Statement
The CCSF CS Department is committed to promoting equity, diversity, and inclusion in the field of computer science. We strive to make computer science accessible and exciting to all, particularly those who are often excluded from or face frequent identity discrimination in the field. If you have a suggestion for how we can better support you and/or your classmates, please reach out to any CS instructor or to the Department Chair. We will make sure your voice is heard.
For more information and resources outside of our department, please visit CCSF's Office of Student Equity.
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 this class, you may decide that you prefer a different style than what is required here. However, in order to get good grades on your programming assignments in this class, you must follow these guidelines.
- Documentation:
Note: If the file is a class header file or a class implementation file, paragraphs A and C do not apply.
A. Initial File Comment: 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. You should expect your initial file comment for the first few assignments to be at least 40 words, and later on in the course you should expect that they will typically be about twice that.
It's good practice to comment important or potentially confusing variables at their declaration, but I won't penalize you for omitting these comments. 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: 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: Just above each of your function definitions (except main()) you must provide a comment describing what the function does. A simple function might have a 15 word comment, while a more complex function might have a comment of around 40 words. Make sure to explain the role of each parameter in your function comments, and refer to them by name. Note: main() does not need a function comment, because this information should be included in the initial file comment.
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: In the case of a class, the header file should begin with a (typically) very large initial file comment. This comment should start by indicating your name, class, date, instructor, name of file, etc. Next it should include a brief general description of the class (so client programmers can tell right away whether they want to use it), followed by a listing of all of the prototypes of public functions, each with pre and post conditions. Note that this list of prototypes is still part of the comment, so 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 and friend functions. Do not include any comments regarding the implementation details in the header file! This initial file 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: 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: Use lots of whitespace (blank lines and spaces) to separate the different parts of your program. 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 are no longer than 80 characters. This includes documentation.
B. With Functions: Put at least 6 blank lines between function definitions.
-
Identifier Names:
A. General: 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: 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:
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 they can be longer if they are simple (for example, lots of cout statements) or if there is just no logical way to break it up. Consider making complex functions (for example, nested loops) even shorter. 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 it does and how just at a glance.
In this class you should rarely write a function longer than 10 lines. There will be exceptions.
-
Indentation:
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:
Make sure that your code is as simple as possible and that there is no unnecessary repeated code.
-
Miscellaneous:
In most cases no numbers other than 1 or 0 should appear in your program, except when being assigned to a global named constant. Other numbers should usually be declared as global named constants. Names of constants should be ALL_UPPERCASE.
Do not use any global variables. In some cases violating this guideline can result in a 0 on an assignment.
-
Do not use break (except in a switch statement), return (except in a value-returning function), exit, or continue.
-
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.
-
Don't mix up statements and expressions. For example, count++ should not be used as an expression, but as a statement.
-
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.
Use a for loop for counter controlled loops. Do not use a for loop for any other kind of loop.
Don't 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.
Use only standard C++.
Don't use typedef
Don't use goto.
Don't use the ?: operator.
Don't use the preprocessor except for #include and for making sure that a header file is not multiply included (#define, #ifndef, and #endif).
Use initializor lists only in derived class constructors.
The characters "== true" or "== false" should never occur in your code.
[a7] 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;
Don't define member functions inside a class declaration.
Do not use a floating point variable to store a quantity that will always be an integer.
If a file includes a main() function, it must be the first function in the file.