Programming HW

# CS 10C - Programming HW

![:newline]

.Huge[*Prof. Ty Feng*]

![:newline]

.Large[UC Riverside - SQ 2026]

![:newline 6]

![:scale 40%](../utils/style/ucr_cs_logo.png)

---

# Overall philosophy

![:flush 1]

.lcol[
![:scale 80%](images/ikea.jpg)
.center.small[Not CS]
]
.rcol[
![:scale 95%](images/carpenter.jpg)
.center.small[Yes, CS!]
]

![:flush 2]

## Using the right tools

- Makefile is a must have for any computer scientists
    - Know your basics, before you can optimize
    - GUIs hide too much of what's happening behind the scene
- Learn how to program with proper programming tools
    - Terminal and command line (UNIX environment)
    - Powerful code editor (e.g., Vim, Emacs)

---

# Automatic grading

## Overview

- Automatic grading is 60% of your homework grade
- (Partially) captures **correctness**
    - *Does your code implement the given specifications?*

![:newline]
## Test cases

- For this first HW, all test cases are provided
- For future HW, some test cases may be intentionally hidden

---

# Manual review

---

## Overview

- Manual review is 40%
- (Partially) captures **quality of program**
- Various aspects related to real-life programming projects
    - Is the project well-packaged?
    - Is the code well-explained?
    - Is the code properly designed and implemented?
    - Does the code follow good coding style?

![:newline]

## Score breakdown

.lcol[
### Easy points
- Submission: ~5%
- Makefile: ~10%
- Coding style: ~15%
]
.rcol[
### Harder points
- Quality of implementation: ~30%
- Report: ~40%
]

---

### Submission

- Submit only what's necessary, nothing more
    - Source code, Makefile, report file
    - Examples of clutter that will affect your submission score: Core dumps,
      backup files, object or executable files, hidden macOS folders
      (`.__MACOSX`, `.DS_Store`), etc.

### Makefile

- g++ with `-Wall -Werror -std=c++11` or `-Wall -Werror -std=c++17`
- Rule for your executable, and `clean` rule
- Can be only a few lines long! (simpler is usually better)

### Coding style

- Linter: fix warnings and errors
- Proper commenting of your code
- Meaningful names for variables (no variables named `tmp` for instance) and
  functions
- Nice horizontal and vertical spacing
- Remove "dead" code
- Etc.

---

### Quality of implementation

- Data structures
    - Use of classes, well-designed, and corresponding to specs, etc.
- Code divided into functions when appropriate
    - No duplicated code, generic functions when possible, etc.
- Memory leaks
- Code quality
    - Grader reads code and makes comments on code
    - At the end, determines the amount of minor and major comments

### Report

- 3 pages max (2 recommended)
- Three parts
    - Intro: What are you trying to show? What is your benchmarking method?
    - Benchmarking: Presentation of *relevant* tables/graphs, and **discussion**
    - Conclusion: Overall analysis of your discussion
- Correct spelling and grammar
- Pay attention to formatting

---

---

## Submission

- Submission via Gradescope only
    * No email submission will be accepted

![:newline]

## Deadline

- Submit on time *(before Wednesday, 11:59pm, PT)*
- If you cannot submit on time due to illness or emergencies, request some slip hours on CourseAssist Extensions page.

---

## Academic integrity

### On your end
- Programs are to be written **from scratch** and **by yourself**
    * No use of AI chatbots/assistants
- Avoid using snippets of code you find online (e.g., stackoverflow)
    - Instead rewrite them yourself
    - Cite your sources

![:flush 1]

### On my end

- Monitor discrepancies between homework grades and exam grades
- Use of MOSS on all submissions + comparison with previous quarters
- If you find existing source code available online
    - Will most likely appear via MOSS!
- Transfer to SCAIP in case of suspected misconduct
    - At best, fail the assignment
    - At worst, fail the class (and even get suspended or dismissed if not first
      referral)

---

# Happy coding! 👩‍💻