Readings
See weekly schedule, or CourSys, for reading response due dates. The readings may be adjusted throughout the semester.
Reading from Clean Code | |
---|---|
1. Chapters 1, 2, 3. | (~50 pages) |
2. Chapters 4, 5, 6. | (~50 pages) |
3. Chapters 7, 8, 9, 10. | (~50 pages) |
4. Chapters 11, 12, 13. | (~40 pages) |
5. Chapters 14 (1 response). See Ch14 special response option below | (~58 pages) |
6. Chapters 15, 16, 17. | (~65 pages) |
Book: Clean Code, Robert C Martin, Prentice Hall, 2009, 9780132350884. SFU Library has physical copies and e-book
Reading Response Requirements
Each reading assignment requires two (2) responses (except Readings 5 requires only 1 but it should be quite strong):
- A single response is free-from written paragraphs (may be multiple paragraphs, need not be an essay) based on some passage in the textbook and incorporates all of the required elements in a clear and well constructed way.
- Each response must quote the textbook's passage which inspired your thought.
- Each response must be at least half a page single-spaced, and no more than a page (unless otherwise stated). Blocks of code in your response do not contribute as much to the overall length of your reply as your written analysis and experience do.
- Select response types from the following (you may use any combination of response types for each reading assignment).
- For each response, state the name of the response option you are doing. For example, give it a title such as: "Ch5: Code in Your Project".
- At most one response per chapter unless there are fewer chapters in a reading than responses to write.
- Unless stated otherwise for the specific response option, you may use the same response option for multiple chapters.
Marking
- [UPDATED - Nov 2021] Marking criteria explained in Reading Response Rubric. It lists:
- Expected length
- Marking scale
- Common deductions
- We will pseudo-randomly choose one of your responses to mark. The other(s) responses will be unmarked. This is done to increase the amount of time our TA(s) can spend on directly helping students instead of marking.
- If a response is obviously lacking, it will be the one that is chosen to be marked.
- If there were
N
required responses, but student submitted onlyM
, then their maximum score is (10 * M / N
)
Reading Response Options
1. Personal Experience
Relate a quote from the course textbook to your personal experience and give an opinion about the quote which is supported by your personal experience. Blend together the following parts into a coherent discussion:
- Quote from the course textbook.
Put it in quotation marks, and cite it by chapter and section (or by chapter and page is OK too). - Personal experience related to the quote.
This must be your personal experience, not some other example (such as IBM in 1980...). Should be from the recent past (vs in grade 2), and should also be a meaningful experience. - An opinion about the quote supported by personal experience.
This is your analysis of the quote stating if you feel it is good, bad, or some other opinion about it related to your personal experience. The point is not to prove the textbook is correct, but to engage with the concepts and think for yourself about its advice.
2. Code in Your Project
Relate a quote from the course text to cleaning up the code in your CMPT 373 project. Find something in your project that violates the suggestion of the textbook. You must:
- Quote from the course textbook.
Put it in quotation marks, and cite it by chapter and section (or by chapter and page is OK too). - Copy project code or explain problem.
Show (copy in the code, draw a UML diagram, ....) the section of code which relates to the quote. - Explain the benefit of the change.
Explain the benefit of applying the textbook's suggestion to your code. Describe the logic behind the way it is currently done in the project. Show what would change if the text's suggestion had been applied to the offending code. Clearly articulate the benefit, with specific reference to your code, of applying the change. You cannot just paraphrase points in the textbook; you must relate them directly to your code. You may bring in your own thoughts and preferences about the previous code and/or new changes. - Refactor!
When reasonable (i.e., not a huge design change), refactor your project code to correct the problem.
3. Somethings You Learned
At most once per set of responses, explain three (or more) important things you learned from the chapter. For each of the things you learned, you must:
- Quote from the readings.
Put it in quotation marks, and cite it by chapter and section (or by chapter and page is OK too). - Explain what you learned.
Clearly articulate what you learned from the quote, and why this change is important. It must be something significant, such as something you feel will strongly contribute to you becoming a better software developer. For example, you cannot use something like "I learned that 'remove' is the opposite of 'add'; I'll try to use that in method names from now on."
You should have about half a page of your thoughts when done. The quotes do not contribute to the length of your response.
4. Reading Discussion Questions
[Questions Added] At most once per set of responses, you may do this reading response. Answer the reading discussion questions for the chapter. Discussion questions only available for a few chapters (currently).
- Copy Question:
Copy all the questions into your response. - Answer Questions:
Answer all questions.
You will not have any quotes from the textbook; just reasonably thought out and explained answers to the questions.
5. Research Something
Research some important point you learned from the readings.
- Quote from the readings.
Put it in quotation marks, and cite it by chapter and section (or by chapter and page is OK too). - Research and explain.
Consult other sources about the truth of, or depth behind, the quote you have mentioned. Clearly articulate why you felt it important to research the quote, and explain what you discovered during your research. It must be something that you felt needed more in depth investigation or that was incorrect in the book. You cannot do something trivial like, "Martin suggested using good variable names, and it turns out wikipedia suggests it too! Who knew!"
6. Summarize the Chapter
At most once per set of responses, provide a point-form summary of the important ideas of the chapter. Make bold (or colour) the points you feel are the important. You must some how indicate where in the book the idea is discussed, such as including page numbers for the first point on a page, or add section headings in your summary. Feel free to add your personal thoughts, but mark them with [ME]
so you can easily keep track of who had the thought (and to reduce your citation burden for this response option).
Your response is likely going to be between 0.75 - 2 pages. It may include quotes, paraphrasing, and your own thoughts; you need not strictly quote the chapter. Your summary is required to be different than the summary of the chapter (if included in the book).
Sample (different book)
* p137: "Any aspect of an interface that can’t be enforced by the compiler is an aspect
that’s likely to be misused." Convert this semantic interface into a “programmatic” one;
use asserts where needed.
* [ME]: What are some ways to automatically find bugs (compile time or run-time)?
* **"I have found that focusing on the abstraction presented by the class interface tends to
provide more insight into class design than focusing on class cohesion"**
* p141: You cannot know that based on the behaviour of the “current” client that your class
can be incomplete without issues. Don’t couple your class to your client.
* ...
7. Discuss in a Group
At most twice per set of responses, pick some important topic(s) of the chapter and discuss them in a group of 2-3 people. You may include people not currently enrolled in the course if you wish. Suggestion: Have each person in the group bring a topic for discussion.
During your discussion, review what the textbook says about the topic(s) and discuss it with each other. Everyone in group is expected to present new ideas, opinions, or examples that relate to the topic(s). Take notes of the discussion.
You must write your own written response (two people may not share the same written response, even if they grouped together to discuss the ideas). Your written response must include:
- Textbook Description of the topic(s)
Include at least one quote (plus include paraphrasing as well if a single quote is not sufficient) from the text to explain what the book says about the topic(s). Cite it with a page number or section. - Summarize group discussion
Provide a written summary of the important points that the group discussed. You do not need to attribute each idea to specific person, and you do not need to quote. Your response should explain to the reader what your group thought of, and possibly what you learned from the discussion.
The combined length of your discussion summarizes (not including the "Textbook Description of the Topic(s)") is expected to be half a page single spaced or more.
8. Other Ideas
If you have additional ideas for response options, please suggest them to me! Good ideas will be accepted and added to the list here for other students to consider too.
9. Ch14 Successive Refinement Extra Option
For Chapter 14, you only need to do one response. You may choose any response; however, here are two options which are tailored specifically for this chapter. Response length limits do not apply here: just answer the questions asked as best you can.
Option A: Analyze the Book's Refactoring
- Read the Args: The Rough Draft section (listings 14-8 through 14-10).
Really dig into the code; do it carefully!
Find one aspect of this code (the "aspect") which bothers you the most or has the most need of improvement. Try to find an aspect that is at a high level, like part of the design of the solution, or how inheritance is used, or how the code processes strings.- Explain what the aspect does in the program.
- Explain what bothers you about the aspect by using correct software engineering terminology.
- Mention at least one idea you have about how you could approach improving this part of the code.
- Read the later parts of the chapter
- Discuss the refactorings that are done to the code which impact this aspect. Don't just restate what happens, discuss why it is done and how it helps.
- Read the code in the Args Implementation section (Listings 14-2 through 14-7).
- Explain how the aspect is implemented in the final version of the code.
- Comment on if this improved the code, and explain if you are satisfied with the updated code.
Option B: Analyze the Final Version
- Read the code in the Args Implementation section (Listings 14-2 through 14-7).
Really dig into the code; do it carefully!
Find one aspect of this code (the "aspect") which bothers you the most or has the most need of improvement. Try to find an aspect that is at a high level, like part of the design of the solution, or how inheritance is used, or how the code processes strings.- Explain what the aspect does in the program.
- Explain what bothers you about the aspect by using correct software engineering terminology.
- Read the rest of the chapter
- Discuss how this feature was implement in the first "rough draft" (listings 14-8 to 14-10).
- Comment on the refactoring done to get from the rough draft to the final version.
- Discuss at least one idea you have about how you could approach improving this aspect in the final version.
Policies
- Late Policy for Readings: 5% penalty per calendar day; maximum 3 days late. Contact the instructor before the deadline if there are extenuating circumstances.
- Extensions and Deferrals: If you are unable to complete an assignment or you will miss an exam due to medical reasons, the University's Health Care Provider Statement is the best form of evidence. Please contact the instructor before the assignment is due or before missing the exam to discuss alternative arrangements.
Academic Honesty
-
Citations
- Your submission must be mostly your own work. It may draw from sources, but should not be either: a) mainly quotes, or b) just paraphrase a single source.
- If you use ideas, quotes, or paraphrase from a source (such as a website, book, podcast, journal article) you must correctly cite the source.
- Citation format is flexible as long as it is clear.
- Failure to cite ideas or text taken from another source is academic dishonesty.
-
For example:
... Code quality is really about two things: 1) having software conform to a specification, and 2) its qualities such as robustness and maintainability (Wikipedia: Software Quality). ... **Sources:** Wikipedia: Software Quality. Accessed Jan 1, 2050. https://en.wikipedia.org/wiki/Software_quality
-
The MOSS tool will be used to check the originality of all electronic submissions.
-
SFU's Academic Honesty policy is crucial to earning credit in this course. Violations of the policy will be taken seriously and reported to the department and university.
-
Explanation of penalties applied for academic dishonesty.