Sample
Dorn/cuda/93
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 9.5Δ 7.2 |
| Scalabrino | 0.216 | 0–1; higher is more readable | 14.7Δ 12.5 |
| Dorn | 0.013 | 0–1; higher is more readable | 1.9Δ 0.3 |
| Mi | 0.055 | 0–1; higher is more readable | 7.8Δ 5.6 |
| LLOC | 19 | Logical lines; fewer is more readable | 35.5Δ 33.3 |
| DeepSeek V4 Pro | 4.67 | 0–20; mean of three runs | 9.2Δ 7.0 |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs | 19.9Δ 17.7 |
| BTTF | 0.252 | 0–1; higher is more readable | 10.3Δ 8.1 |
| Human | 1.9 | 1–5; original rating | 2.2 |
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) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 2194.283 | −72.411 |
| Source linesThe number of non-empty source lines. | 30 | +12 |
| 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.049 | −7.574 |
Intercept 8.87 + feature contributions = -59.115 (log-odds).
Score = sigmoid(-59.115) = 0.
| Score | 0.216 |
|---|
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. | 143.968 | −2.433 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 28 | −0.222 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.12 | −0.222 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 31 | −0.061 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 29.876 | +0.008 |
Intercept 0.07 + feature contributions = -4.366 (log-odds).
Score = sigmoid(-4.366) = 0.013.
| Score | 0.055 |
|---|
| Score | 19 |
|---|
Run 1
The code is highly repetitive and uses very long variable names and function calls, making it difficult to read. It appears to be a CUDA kernel but is presented with line-continuation backslashes, suggesting it was extracted from a macro definition. The structure is linear but lacks abstraction; functions like LoadMD5RegistersFromGlobalMemory take 17 arguments, obscuring intent. Nesting is shallow, which is good, but the visual clutter from repeated b0-b15 parameters and multi-line calls hurts readability. Clarity of intent is moderate: it performs MD5 chain generation, but the repeated register names dominate the logic. Code length is excessive for what it does; a struct or array for MD5 registers would greatly condense it. Action granularity is inconsistent: some lines combine multiple operations, while others spread a single call across many lines. Reading flow suffers from the lack of whitespace, comments, and meaningful grouping. Overall, the code is functional but not written for human readability.
Run 2
This code is extremely difficult to read due to multiple factors. The heavy use of backslash line continuations suggests it exists within a macro definition, which immediately obscures the logical structure and intent. Function calls span multiple lines with excessive parameters (15+ variables), making the code vertically bloated and horizontally unreadable. There is virtually no whitespace or logical grouping within expressions, and variable names like b0-b15, a, b, c, d are cryptic and provide no semantic meaning. The nesting levels are shallow (two if/else blocks, one for loop), but the action granularity is poor because single logical operations are split across multiple lines due to parameter count. The reading flow is disorganized, jumping from global memory loads to MD5 hashing to character set reduction without any comments explaining the chain-generation algorithm. Overall, the code lacks clarity, is unnecessarily verbose due to repetitive parameter passing, and would be nearly incomprehensible to a new developer without external documentation.
Run 3
The code is extremely difficult to read. It uses macro-style line continuations (backslashes) throughout, making it appear as one massive preprocessor block rather than a coherent function. The function calls have 15+ parameters with cryptic names (b0-b15, a, b, c, d), obscuring intent. There is no whitespace, indentation, or logical grouping to separate the bounds check, initialization, loop body, and output. Nesting is moderate but buried under the poor formatting. Action granularity is violated with multiple operations per line (e.g., combining arithmetic, function calls, and increments). Reading flow is nonexistent—the reader must constantly track macro definitions and parameter positions. The variable names lack semantic meaning, and the dense sequential operations make it nearly impossible to discern the algorithm's purpose without external documentation. Overall, this is unreadable code.
Run 1
Code Structure: Logically organized into thread indexing, bounds checking, initialization, hash/reduction iterations, and result storage. Nesting: Shallow, with one loop and simple conditionals; the early return reduces nesting. Clarity of intent: Descriptive function names convey the overall workflow, but register names, CUDA-specific indexing, and unexplained chain parameters require domain knowledge. Code length: Reasonably concise overall, though repeated register lists and lengthy identifiers make lines cumbersome. Action granularity: Mostly one operation per line, with function calls grouping related work appropriately. Reading flow: Execution follows a natural sequence, but macro-continuation backslashes, inconsistent spacing, long argument lists, and incorrect indentation in the final else block interrupt scanning.
Run 2
Code Structure: A logical sequence covers thread indexing, bounds checking, initialization, iterative hashing, and result storage. Nesting: Mostly shallow, with only one conditional inside the loop. Clarity of intent: Descriptive function names communicate major operations, but cryptic register variables, undocumented chain logic, and inconsistent naming reduce clarity. Code length: Reasonably compact overall, though repeated register lists and verbose indexing expressions add visual bulk. Action granularity: Generally one operation per line; multiline function calls remain coherent. Reading flow: Execution proceeds naturally, but macro continuation backslashes, long lines, inconsistent spacing, and poor indentation in the final else block interrupt scanning.
Run 3
Code Structure: Logical phases—index calculation, bounds checking, initialization, iterative hashing/reduction, and saving—are identifiable. Nesting: Shallow nesting and an early return keep control flow manageable. Clarity of intent: Descriptive function names suggest the purpose, but cryptic register names, unexplained parameters, and absent comments obscure algorithm details. Code length: The snippet is compact, but repeated register lists and lengthy identifiers make lines cumbersome. Action granularity: Most lines contain one action, although function calls have many arguments that increase cognitive load. Reading flow: Execution proceeds naturally, but macro-continuation backslashes, inconsistent spacing, and poor indentation in the final else block interrupt readability.