Source code
Official dataset source · Dorn/cuda/111
Sample
Dorn/cuda/111
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.949 | 0–1; higher is more readable | 91.1Δ 34.3 |
| Scalabrino | 0.606 | 0–1; higher is more readable | 59.7Δ 2.9 |
| Dorn | 0.794 | 0–1; higher is more readable | 77.2Δ 20.3 |
| Mi | 0.663 | 0–1; higher is more readable | 75.5Δ 18.7 |
| LLOC | 5 | Logical lines; fewer is more readable | 78.0Δ 21.2 |
| DeepSeek V4 Pro | 11 | 0–20; mean of three runs | 46.4Δ 10.4 |
| GPT-6.1 Sol | 13.67 | 0–20; mean of three runs | 37.7Δ 19.1 |
| BTTF | 0.594 | 0–1; higher is more readable | 72.1Δ 15.3 |
| Human | 3.41 | 1–5; original rating | 56.8 |
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) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 29 | +11.6 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 302.863 | −9.994 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 5.038 | −7.557 |
Intercept 8.87 + feature contributions = 2.919 (log-odds).
Score = sigmoid(2.919) = 0.949.
| Score | 0.606 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.04 | +0.558 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 81.833 | +0.516 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 11 | −0.357 |
| 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. | 81.9 | +0.196 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 30 | −0.026 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 28.928 | −0.005 |
Intercept 0.07 + feature contributions = 1.35 (log-odds).
Score = sigmoid(1.35) = 0.794.
| Score | 0.663 |
|---|
| Score | 5 |
|---|
Run 1
The code opens with a lengthy license block that obscures the actual logic, hurting immediate clarity. Structure is reasonable, with includes and a kernel definition, but mixed tabs/spaces and inconsistent indentation reduce readability. Nesting is flat, and there is one action per line, which is good. However, clarity of intent suffers because the kernel's purpose is not immediately obvious, and variable names like 'idnx' and 'idny' are slightly ambiguous. The code is concise but incomplete, so length is not an issue. Reading flow is disrupted by inconsistent formatting and a large header comment before any functional code. Overall, it is understandable but lacks polish and consistent style.
Run 2
The code has moderate readability. The header comment and includes are clear, and variable declarations use one action per line. However, the kernel function lacks clear intent — parameters are not self-documenting, and there is no explanatory comment about what 'CenterAttribution' does. The code is short, which helps, but the logic is incomplete and ends abruptly. Indentation is inconsistent between tabs and spaces, and the unused variables 'bx' and 'by' reduce clarity. Overall, the structure is basic but not well organized or explained.
Run 3
The code starts with a clear license header and includes, which aids legal clarity. However, the actual function logic is minimal and has several readability issues. The function signature is clear but the body suffers from inconsistent indentation (mixing tabs and spaces), redundant variable assignments (bx and by are declared but unused), and unclear variable naming like 'idnx' and 'idny' which are not immediately descriptive. The code is quite short, which is good, but it lacks comments explaining the purpose or the semantics of the kernel. Nesting is not an issue here since the code is flat. Action granularity is adequate but the reading flow is interrupted by formatting inconsistencies. The intent of the code is somewhat ambiguous without context about what 'CenterAttribution' is supposed to accomplish. Overall, while not unreadable, the mixed indentation and lack of explanatory comments lower its readability score. There are no deeply nested control structures, which is a positive, but clarity and structure need improvement.
Run 1
Code Structure: Includes and the kernel declaration are logically ordered, but the snippet ends before the function is completed. Nesting: Flat, with no nested control flow. Clarity of intent: CenterAttribution suggests a purpose, and CUDA index calculations are recognizable, but abbreviated names such as bx, by, idnx, and idny lack explanation; the actual attribution logic is absent. Code length: The executable portion is concise; the lengthy license header is standard rather than unnecessary logic. Action granularity: Each declaration and calculation occupies its own line. Reading flow: Straightforward top-to-bottom progression, weakened by inconsistent indentation, tight operator spacing, and the abrupt ending.
Run 2
Code Structure: Includes and the kernel declaration are logically ordered, but the snippet ends mid-function, limiting assessment of its organization. Nesting: The visible code is flat and easy to scan. Clarity of intent: CenterAttribution suggests the kernel's purpose, and CUDA index calculations are recognizable, but abbreviated names such as bx, by, idnx, and idny lack explanation; the parameters' roles are not demonstrated. Code length: The executable portion is concise, although the lengthy license header dominates this small excerpt. Action granularity: Each declaration or calculation occupies its own line. Reading flow: Execution proceeds naturally from block indices to thread coordinates, but inconsistent indentation and spacing reduce visual consistency, and the abrupt ending leaves the logic incomplete.
Run 3
Code Structure: Includes and the kernel declaration are logically organized, but the excerpt ends before the function is complete. Nesting: The visible body is flat and easy to scan. Clarity of intent: CenterAttribution and the coordinate calculations suggest CUDA thread indexing, but abbreviated names such as bx, by, idnx, and idny lack explanation, and the kernel's actual attribution logic is absent. Code length: The executable portion is concise; the lengthy license header adds scrolling but serves a legitimate purpose. Action granularity: Each declaration performs one clear action per line. Reading flow: The sequence from includes to kernel to index calculations is natural, although inconsistent indentation, tight operator spacing, and the incomplete ending reduce readability.