Sample
Dorn/cuda/70
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.964 | 0–1; higher is more readable | 92.2Δ 21.7 |
| Dorn | 0.843 | 0–1; higher is more readable | 83.8Δ 13.4 |
| Mi | 0.684 | 0–1; higher is more readable | 78.8Δ 8.4 |
| LLOC | 4 | Logical lines; fewer is more readable | 82.7Δ 12.3 |
| DeepSeek V4 Pro | 7 | 0–20; mean of three runs | 22.7Δ 47.8 |
| GPT-6.1 Sol | 11.67 | 0–20; mean of three runs | 16.9Δ 53.6 |
| BTTF | 0.542 | 0–1; higher is more readable | 56.8Δ 13.6 |
| Human | 3.6 | 1–5; original rating | 70.5 |
Views
Select the downloaded ZIP or its extracted folder. Files stay in your browser.
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 4.318 | −6.476 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 93.765 | −3.094 |
Intercept 8.87 + feature contributions = 3.299 (log-odds).
Score = sigmoid(3.299) = 0.964.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 10 | +0.682 |
| Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names. | 72 | +0.616 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.042 | +0.539 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 7 | −0.495 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 9.795 | −0.273 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 58.909 | +0.146 |
Intercept 0.07 + feature contributions = 1.683 (log-odds).
Score = sigmoid(1.683) = 0.843.
| Score | 0.684 |
|---|
| Score | 4 |
|---|
Run 1
The code is generally readable but incomplete. It defines two structs with clear purpose: `kernLaunch` for kernel launch data and `kernLaunchLL` for a linked list node with a guest PID. Naming is descriptive (kernPtr, kernName, fatBin, guest_pid) and comments clarify intent. The structure is flat and organized logically. However, the snippet lacks context — the opening brace before `kernPtr` suggests it is the tail end of a struct, and no closing semicolon is shown for `kernLaunchLL`, making the code fragment ambiguous. Action granularity is fine (one field per line), but the incomplete boundaries reduce clarity. Overall, concise and well-commented, but missing surrounding code prevents full readability assessment.
Run 2
The code is highly fragmented and lacks context: the first block opens with three struct members that have no visible struct definition (the opening brace is missing from the snippet), making it appear as dangling fields. Comments like 'Pointer identifier' and 'Kernel name as in code' are redundant and do not clarify intent. The second struct is incomplete and ambiguously mixes a launch data struct with a PID field, but its purpose is unclear. Indentation is inconsistent, and there is no separation between the two structures. The snippet ends abruptly, suggesting the full code may be more organized, but as presented it is confusing and unreadable.
Run 3
This code snippet is largely unreadable and incomplete. It begins with what appears to be the tail end of a struct or variable declarations, lacking context or a clear opening. The comments are ambiguous ('Pointer identifier' does not clarify purpose). There is no cohesive structure or function definition, and the snippet cuts off mid-declaration. While indentation is mostly consistent, the lack of surrounding code and meaningful context makes intent unclear. The code is not deeply nested, but it is fragmented and disorganized. It is hard to judge action granularity or reading flow because no actions are performed. Overall, it fails to convey a clear logical purpose or useful information on its own, warranting a very low readability score.
Run 1
Code Structure: Fields are grouped logically, and the linked-list structure is introduced clearly, but the fragment starts and ends inside incomplete definitions. Nesting: Flat declarations are easy to scan. Clarity of intent: Comments explain some fields and the PID association, but abbreviated names and the undocumented fatBin field reduce clarity; no list link is visible. Code length: Concise, without unnecessary implementation. Action granularity: Each declaration occupies its own line. Reading flow: Consistent spacing and the separating comment help, but missing surrounding definitions and the unfinished structure interrupt comprehension.
Run 2
Code Structure: Related fields and a linked-list structure are logically grouped, but the fragment starts inside an unspecified structure and ends before the next structure closes. Nesting: Shallow and easy to follow. Clarity of intent: Comments explain some fields and the structure's purpose, but abbreviations such as kernPtr and fatBin are less explicit, and no linked-list link is shown. Code length: Concise, with no obvious unnecessary code. Action granularity: Each declaration occupies its own line. Reading flow: Straightforward locally, though incomplete context and inconsistent spacing around the opening brace reduce readability.
Run 3
Code Structure: Fields are grouped sensibly, and the linked-list comment introduces a related structure, but the fragment begins and ends inside incomplete declarations. Nesting: Shallow structure with no deeply nested logic. Clarity of intent: Comments clarify kernPtr, kernName, and the PID association, while fatBin is unexplained and the shown linked-list structure lacks a link field. Code length: Concise, without obvious redundancy. Action granularity: Each declaration occupies its own line. Reading flow: Mostly straightforward, but abbreviated identifiers, inconsistent brace spacing, and missing surrounding definitions interrupt comprehension.