Sample
Dorn/cuda/16
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 11.4Δ 10.0 |
| Scalabrino | 0.068 | 0–1; higher is more readable | 3.5Δ 2.1 |
| Dorn | 0.193 | 0–1; higher is more readable | 16.2Δ 14.8 |
| Mi | 0.154 | 0–1; higher is more readable | 15.6Δ 14.2 |
| LLOC | 17 | Logical lines; fewer is more readable | 41.2Δ 39.8 |
| DeepSeek V4 Pro | 3 | 0–20; mean of three runs | 3.2Δ 1.8 |
| GPT-6.1 Sol | 6.67 | 0–20; mean of three runs | 1.1Δ 0.3 |
| BTTF | 0.412 | 0–1; higher is more readable | 25.9Δ 24.5 |
| Human | 1.72 | 1–5; original rating | 1.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) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 1908.314 | −62.974 |
| 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.102 | −7.652 |
Intercept 8.87 + feature contributions = -49.757 (log-odds).
Score = sigmoid(-49.757) = 0.
| Score | 0.068 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| 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. | 95.839 | −0.394 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 30 | +0.301 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.126 | −0.279 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 30 | −0.268 |
| 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.938 | +0.009 |
Intercept 0.07 + feature contributions = -1.427 (log-odds).
Score = sigmoid(-1.427) = 0.193.
| Score | 0.154 |
|---|
| Score | 17 |
|---|
Run 1
This code is extremely difficult to read and understand. It appears to be a macro definition or fragment with excessive line continuations, deeply cryptic variable names (p0-p47, b0-b15), and multiple function calls with 20+ parameters each. There is no logical structure visible, no comments explaining intent, and no meaningful naming conventions. The code consists of multiple actions crammed into single logical blocks with no separation of concerns. The reading flow is completely disorganized, jumping between hash operations, bitmap checks, and counter increments without clear transitions. Nesting is minimal but the parameter count and macro complexity create equivalent cognitive load. While this may be performance-optimized CUDA code, the readability is severely compromised by the sheer density of parameters, lack of whitespace, and opaque variable names.
Run 2
This code is extremely difficult to read due to heavy macro usage, multi-line continuations, and unclear intent. The structure appears tangled with many variables passed across lines without clear organization. Nesting is minimal but the macro expansion creates visual clutter. Intent is ambiguous—function names like 'checkDuplicatedHashMultiLong' hint at purpose, but the overall flow is obscured by repeated parameter lists. Code length is excessive for what appears to be repetitive kernel instantiations. Multiple actions are packed into single macro lines, violating one-action-per-line. Reading flow is disorganized due to backslash continuations and inconsistent indentation. The repeated macro calls at the bottom offer no clarity about their effect. Overall, this requires deep domain knowledge to parse and is not maintainable in its current form.
Run 3
This code is extremely difficult to read. It appears to be a fragment of a CUDA macro definition for generating password-cracking kernels, but it lacks context (macro opening, parameters, types). The structure is tangled: long parameter lists are split across multiple lines with line-continuation backslashes, mixing unrelated variables (p*, b*, a-d, counters) without clear grouping. Nesting is not the issue; instead, the problem is dense, repetitive arguments with no abstraction. Intent is ambiguous—function names like 'checkDuplicatedHashMultiLong' hint at purpose, but the macro pattern obscures logic. Code length is excessive for what is shown, though some verbosity may be unavoidable in GPU kernel launches. Action granularity is poor: multiple operations (hash computation, checking, counter increment) are packed into consecutive macro calls with no spacing or comments. Reading flow is disorganized, jumping from variable declarations to function calls to macro invocations without logical breaks. Overall, only maintainable by someone already intimately familiar with the codebase.
Run 1
Code Structure: Macro-based kernel generation provides some organization, but the fragment starts mid-call and hides its enclosing structure. Nesting: Visible nesting is limited, although closing braces without opening context obscure scope. Clarity of intent: MD4 hashing, hash checking, and counter increments are recognizable, but terse variable names, extensive positional arguments, and token pasting hinder understanding. Code length: Long parameter lists and thirteen repeated macro invocations create substantial visual repetition. Action granularity: Statements generally represent one action each, though macro expansion conceals the actual operations. Reading flow: Hashing, checking, and incrementing form a logical sequence, but inconsistent indentation, continuation backslashes, and dense argument lists interrupt scanning.
Run 2
Code Structure: Macro-based kernel generation provides some organization, but the fragment begins mid-call and lacks surrounding context. Nesting: Visible nesting is limited, though unmatched closing braces and macro continuations obscure block boundaries. Clarity of intent: Hashing, checking results, and incrementing counters are recognizable, but numbered variables and extensive positional arguments make data roles difficult to understand. Code length: Long argument lists and thirteen repeated macro invocations add visual bulk, although macros avoid duplicating entire kernels. Action granularity: Each statement generally performs one action, but statements span many lines and contain dense argument lists. Reading flow: The operation sequence is reasonably logical, but inconsistent indentation, backslash continuations, and token-pasting syntax interrupt natural reading.
Run 3
Code Structure: A hashing, checking, and counter-update sequence is visible, followed by kernel generation, but the incomplete macro fragment obscures its organization. Nesting: Visible nesting is limited, although unmatched closing braces and missing context make scope unclear. Clarity of intent: Function names suggest password hashing and matching, but numbered variables, large argument lists, and token concatenation impede understanding. Code length: Repeated kernel invocations and exhaustive parameter lists make the snippet verbose, though macro generation avoids duplicating complete kernels. Action granularity: Statements generally perform one action each, but individual calls require tracking many arguments across lines. Reading flow: Inconsistent indentation, continuation backslashes, and the abrupt opening mid-call disrupt otherwise sequential execution.