Sample
Dorn/cuda/72
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.804 | 0–1; higher is more readable | 85.8Δ 80.4 |
| Scalabrino | 0.576 | 0–1; higher is more readable | 55.8Δ 50.4 |
| Dorn | 0.354 | 0–1; higher is more readable | 28.4Δ 23.0 |
| Mi | 0.179 | 0–1; higher is more readable | 18.4Δ 13.0 |
| LLOC | 2 | Logical lines; fewer is more readable | 93.7Δ 88.3 |
| DeepSeek V4 Pro | 3.33 | 0–20; mean of three runs | 4.6Δ 0.8 |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs | 30.6Δ 25.2 |
| BTTF | 0.254 | 0–1; higher is more readable | 10.6Δ 5.2 |
| Human | 2.12 | 1–5; original rating | 5.4 |
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. | 5.122 | −7.684 |
| Source linesThe number of non-empty source lines. | 9 | +3.6 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 102.187 | −3.372 |
Intercept 8.87 + feature contributions = 1.414 (log-odds).
Score = sigmoid(1.414) = 0.804.
| Score | 0.576 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 112 | −1.079 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 10 | +0.682 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 6 | −0.53 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.055 | +0.404 |
| 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. | 8.965 | −0.285 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 33.6 | −0.262 |
Intercept 0.07 + feature contributions = -0.601 (log-odds).
Score = sigmoid(-0.601) = 0.354.
| Score | 0.179 |
|---|
| Score | 2 |
|---|
Run 1
The code is extremely difficult to evaluate fully due to being an incomplete snippet, but several major readability issues are evident. Structure is fragmented, starting mid-function with commented-out memory allocation lines that clutter the code. Nesting is minimal but meaningless without context. Intent is unclear—there's no explanation of what the kernel launch does, what G1/B1 represent, or why certain lines are commented. Length is short but unhelpful. Action granularity is acceptable (one kernel launch per major line), but the commented-out code violates clean-code principles by leaving dead artifacts. Reading flow is poor because it begins abruptly and ends with a stray closing brace. Overall, this snippet fails readability standards due to missing context, dead code, and unexplained parameters.
Run 2
The code is largely unreadable due to several issues. It contains commented-out code, making the active logic unclear. The structure is tangled: there are unexplained macros (CUDA_SAFE_CALL), pointer dereferencing, and a kernel launch with undefined variables (G1, B1). The nesting is minimal, but clarity of intent is very low—variable names like d_activity and d_attenuation are somewhat descriptive, yet no context or comments explain the purpose. The code length is short, but the action granularity is poor because multiple operations (kernel launch, synchronize call) are crammed with minimal separation. The reading flow is disorganized, jumping from unused allocations to a kernel launch, then a synchronize, without logical progression or explanation. Overall, it appears as a fragment with missing context, making it difficult to understand or maintain.
Run 3
The code is highly unreadable due to commented-out lines, cryptic variable names, lack of context, and unexplained CUDA kernel launch parameters. The structure is disorganized, with dead code mixed with active code. The kernel launch line is dense and ambiguous, combining multiple operations without clarity of intent. Variable names like 'd_activity', 'd_attenuation', 'G1', and 'B1' are not descriptive. There is no surrounding function definition or comments explaining purpose. The reading flow is poor, with abandoned code creating confusion. The only positive aspect is that the active code is relatively short, but it is not self-explanatory.
Run 1
Code Structure: The kernel launch followed by synchronization is logically organized, but the unmatched closing brace and commented-out allocation code obscure the surrounding structure. Nesting: The visible operations are flat and easy to scan. Clarity of intent: The descriptive kernel name suggests an attenuated line-integral computation, though G1, B1, and pointer dereferences require external context. Code length: The active code is concise, but obsolete-looking comments add clutter. Action granularity: Each active statement performs one distinct action. Reading flow: Launching the kernel and then synchronizing follows a natural sequence, while inconsistent spacing and the incomplete scope reduce readability.
Run 2
Code Structure: The kernel launch and synchronization form a logical sequence, but the unmatched closing brace and missing surrounding context make the snippet structurally incomplete. Nesting: The visible code is flat and easy to scan. Clarity of intent: Descriptive kernel and argument names suggest an attenuated line-integral computation, while G1 and B1 leave launch configuration unclear. Code length: The active code is concise, but two commented-out allocation lines add clutter. Action granularity: Each active statement performs one action. Reading flow: Launching the kernel before synchronization is natural, although dead comments, extra whitespace, and the trailing brace interrupt the flow.
Run 3
Code Structure: The active statements form a logical kernel-launch-then-synchronize sequence, but the unmatched closing brace and missing surrounding context weaken organization. Nesting: The visible code is flat and easy to scan. Clarity of intent: The descriptive kernel name suggests an attenuated line-integral computation, though G1, B1, and pointer arguments lack explanation. Code length: The active code is concise, but two commented-out allocation statements add clutter. Action granularity: Each active statement performs one clear action. Reading flow: Execution order is natural, although inconsistent spacing, leading indentation, and obsolete comments interrupt the flow.