|
| 1 | +# Code Review Guidelines |
| 2 | + |
| 3 | +These guidelines are derived from analysis of code reviews across the bootc-dev |
| 4 | +organization (October–December 2024). They represent the collective expectations |
| 5 | +and standards that have emerged from real review feedback. |
| 6 | + |
| 7 | +## Testing |
| 8 | + |
| 9 | +Tests are expected for all non-trivial changes - unit and integration by default. |
| 10 | + |
| 11 | +If there's something that's difficult to write a test for at the current time, |
| 12 | +please do at least state if it was tested manually. |
| 13 | + |
| 14 | +### Choosing the Right Test Type |
| 15 | + |
| 16 | +Unit tests are appropriate for parsing logic, data transformations, and |
| 17 | +self-contained functions. Use integration tests for anything that involves |
| 18 | +running containers or VMs. |
| 19 | + |
| 20 | +Default to table-driven tests instead of having a separate unit test per |
| 21 | +case. Especially LLMs like to generate the latter, but it can become |
| 22 | +too verbose. Context windows matter to both humans and LLMs reading the |
| 23 | +code later (this applies outside of unit tests too of course, but it's |
| 24 | +easy to generate a *lot* of code for unit tests unnecessarily). |
| 25 | + |
| 26 | +### Separating Parsing from I/O |
| 27 | + |
| 28 | +A recurring theme is structuring code for testability. Split parsers from data |
| 29 | +reading: have the parser accept a `&str`, then have a separate function that |
| 30 | +reads from disk and calls the parser. This makes unit testing straightforward |
| 31 | +without filesystem dependencies. |
| 32 | + |
| 33 | +### Test Assertions |
| 34 | + |
| 35 | +Make assertions strict and specific. Don't just verify that code "didn't crash"— |
| 36 | +check that outputs match expected values. When adding new commands or output |
| 37 | +formats, tests should verify the actual content, not just that something was |
| 38 | +produced. |
| 39 | + |
| 40 | +## Code Quality |
| 41 | + |
| 42 | +### Parsing Structured Data |
| 43 | + |
| 44 | +Never parse structured data formats (JSON, YAML, XML) with text tools like `grep` |
| 45 | +or `sed`. |
| 46 | + |
| 47 | +### Shell Scripts |
| 48 | + |
| 49 | +Try to avoid having shell script longer than 50 lines. This commonly occurs |
| 50 | +in build system and tests. For the build system, usually there's higher |
| 51 | +level ways to structure things (Justfile e.g.) and several of our projects |
| 52 | +use the `cargo xtask` pattern to put arbitrary "glue" code in Rust using |
| 53 | +the `xshell` crate to keep it easy to run external commands. |
| 54 | + |
| 55 | +### Constants and Magic Values |
| 56 | + |
| 57 | +Extract magic numbers into named constants. Any literal number that isn't |
| 58 | +immediately obvious—buffer sizes, queue lengths, retry counts, timeouts—should |
| 59 | +be a constant with a descriptive name. The same applies to magic strings: |
| 60 | +deduplicate repeated paths, configuration keys, and other string literals. |
| 61 | + |
| 62 | +When values aren't self-explanatory, add a comment explaining why that specific |
| 63 | +value was chosen. |
| 64 | + |
| 65 | +### Don't ignore (swallow) errors |
| 66 | + |
| 67 | +Avoid the `if let Ok(v) = ... { }` in Rust, or `foo 2>/dev/null || true` |
| 68 | +pattern in shell script by default. Most errors should be propagated by |
| 69 | +default. If not, it's usually appropriate to at least log error messages |
| 70 | +at a `tracing::debug!` or equivalent level. |
| 71 | + |
| 72 | +Handle edge cases explicitly: missing data, malformed input, offline systems. |
| 73 | +Error messages should provide clear context for diagnosis. |
| 74 | + |
| 75 | +### Code Organization |
| 76 | + |
| 77 | +Separate concerns: I/O operations, parsing logic, and business logic belong in |
| 78 | +different functions. Structure code so core logic can be unit tested without |
| 79 | +external dependencies. |
| 80 | + |
| 81 | +It can be OK to duplicate a bit of code in a slightly different form twice, |
| 82 | +but having it happen in 3 places asks for deduplication. |
| 83 | + |
| 84 | +## Commits and Pull Requests |
| 85 | + |
| 86 | +### Commit Organization |
| 87 | + |
| 88 | +Break changes into logical, atomic commits. Reviewers appreciate being able to |
| 89 | +follow your reasoning: "Especially grateful for breaking it up into individual |
| 90 | +commits so I can more easily follow your train of thought." |
| 91 | + |
| 92 | +Preparatory refactoring should be separate from behavioral changes. Each commit |
| 93 | +should tell a clear story and be reviewable independently. Where applicable, |
| 94 | +create "prep" commits that could be merged separately from the behavioral change. |
| 95 | + |
| 96 | +### Commit Messages |
| 97 | + |
| 98 | +Write clear and descriptive commit messages using a `component: Summary` |
| 99 | +subject, such as `kernel: Add find API w/correct hyphen-dash equality, add docs`. |
| 100 | +Use imperative mood: "Add integration with..." not "Adds integration with...". |
| 101 | + |
| 102 | +The body of the commit should start with at least one sentence (or paragraph) |
| 103 | +describing **why** the change is being made, even for something apparently |
| 104 | +trivial. For example a "refactor" commit might have a "why" rationale of just |
| 105 | +"Prep for handling X later." A big commit introducing a feature may seem |
| 106 | +self-explanatory, but there is often ambient context like "A large-scale Debian |
| 107 | +user wanted this" that provides helpful grounding in the motivation. |
| 108 | + |
| 109 | +If there's a linked tracking issue, often that will contain a more extensive |
| 110 | +rationale that doesn't need to be duplicated entirely in the commit message, |
| 111 | +but do ensure the commit message has something useful on its own for a rationale. |
| 112 | + |
| 113 | +Keep it natural and concise. A few sentences of prose explaining the design |
| 114 | +intent or the high-level data flow is often good enough. If there's a |
| 115 | +non-obvious consequence of the change, call it out briefly (e.g. "Note the |
| 116 | +manifest becomes part of the GC root") rather than explaining the full |
| 117 | +mechanism. Think about what a reviewer needs to know that may not be obvious |
| 118 | +from a skim of the code. |
| 119 | + |
| 120 | +Do not restate obvious parts of what is already visible in the commit diff: |
| 121 | + |
| 122 | +- "Changed function X to call Y" |
| 123 | +- Generic `Changes:` sections with bulleted lists of implementation details |
| 124 | +- "Files changed" sections — completely redundant with git |
| 125 | + |
| 126 | +Implementation details belong in the code documentation. The goal of the |
| 127 | +commit message is like a "cover letter" for the change, with a primary |
| 128 | +rationale of why the change is being made, alongside a concise summary of |
| 129 | +its implementation. |
| 130 | + |
| 131 | +Another thing that can go in the commit message is brief descriptions |
| 132 | +of alternative approaches that were considered and discarded. |
| 133 | + |
| 134 | +Closes: tags should generally come at the end of the commit message. |
| 135 | + |
| 136 | +### PR Descriptions |
| 137 | + |
| 138 | +Generally, just restate the commit message. |
| 139 | + |
| 140 | +Where it makes sense, it is OK to include additional details though. |
| 141 | + |
| 142 | +### Further changes on top of existing commits |
| 143 | + |
| 144 | +If you have followup fixes (whether that's part of a local loop or |
| 145 | +as part of addressing PR review), it is generally encouraged to *squash* |
| 146 | +the fixes into the prior commit. Do not create generically-named "Update <file>" commits |
| 147 | +or "Address review feedback" or "Fix cargo fmt" commits. |
| 148 | + |
| 149 | +This applies equally when an AI tool (e.g. Gemini, Copilot) suggests a |
| 150 | +change via a review comment — applying the suggestion creates a new commit |
| 151 | +with an auto-generated subject. That commit should be squashed before the |
| 152 | +PR is merged. |
| 153 | + |
| 154 | +In other words either a commit "stands alone" with its own rationale or it doesn't. |
| 155 | + |
| 156 | +### Keeping PRs Current |
| 157 | + |
| 158 | +Keep PRs rebased on main. When CI failures are fixed in other PRs, rebase to |
| 159 | +pick up the fixes. Reference the fixing PR when noting that a rebase is needed. |
| 160 | + |
| 161 | +### Before Merge |
| 162 | + |
| 163 | +Self-review your diff before requesting review. Catch obvious issues yourself |
| 164 | +rather than burning reviewer cycles. |
| 165 | + |
| 166 | +Do not add `Signed-off-by` lines automatically—these require explicit human |
| 167 | +action after review. If code was AI-assisted, include an `Assisted-by:` trailer |
| 168 | +indicating the tool and model used. |
| 169 | + |
| 170 | +## Architecture and Design |
| 171 | + |
| 172 | +### Workarounds vs Proper Fixes |
| 173 | + |
| 174 | +When implementing a workaround, document where the proper fix belongs and link |
| 175 | +to relevant upstream issues. Invest time investigating proper fixes before |
| 176 | +settling on workarounds. |
| 177 | + |
| 178 | +### Cross-Project Considerations |
| 179 | + |
| 180 | +Prefer pushing fixes upstream when the root cause is in a dependency. Reduce |
| 181 | +scope where possible; don't reimplement functionality that belongs elsewhere. |
| 182 | + |
| 183 | +When multiple systems interact (like Renovate and custom sync tooling), be |
| 184 | +explicit about which system owns what and how they coordinate. |
| 185 | + |
| 186 | +### Avoiding Regressions |
| 187 | + |
| 188 | +Verify that new code paths handle all cases the old code handled. When rewriting |
| 189 | +functionality, ensure equivalent coverage exists. |
| 190 | + |
| 191 | +### Review Requirements |
| 192 | + |
| 193 | +When multiple contributors co-author a PR, bring in an independent reviewer. |
| 194 | + |
| 195 | +## Rust-Specific Guidance |
| 196 | + |
| 197 | +Prefer rustix over `libc`. All `unsafe` code must be very carefully |
| 198 | +justified. |
| 199 | + |
| 200 | +### Dependencies |
| 201 | + |
| 202 | +New dependencies should be justified. Glance at existing reverse dependencies |
| 203 | +on crates.io to see if a crate is widely used. Consider alternatives: "I'm |
| 204 | +curious if you did any comparative analysis at all with alternatives?" |
| 205 | + |
| 206 | +Prefer well-maintained crates with active communities. Consider `cargo deny` |
| 207 | +policies when adding dependencies. |
| 208 | + |
| 209 | +### API Design |
| 210 | + |
| 211 | +When adding new commands or options, think about machine-readable output early. |
| 212 | +JSON is generally preferred for that. |
| 213 | + |
| 214 | +Keep helper functions in appropriate modules. Move command output formatting |
| 215 | +close to the CLI layer, keeping core logic functions focused on their primary |
| 216 | +purpose. |
0 commit comments