Sample
Dorn/cuda/19
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.001 | 0–1; higher is more readable | 59.3Δ 16.4 |
| Dorn | 0.519 | 0–1; higher is more readable | 44.6Δ 31.2 |
| Mi | 0.242 | 0–1; higher is more readable | 23.4Δ 52.4 |
| LLOC | 10 | Logical lines; fewer is more readable | 59.5Δ 16.3 |
| DeepSeek V4 Pro | 9.67 | 0–20; mean of three runs | 39.4Δ 36.4 |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs | 19.9Δ 55.8 |
| BTTF | 0.257 | 0–1; higher is more readable | 11.1Δ 64.6 |
| Human | 3.68 | 1–5; original rating | 75.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) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 633.309 | −20.899 |
| 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. | 4.708 | −7.062 |
Intercept 8.87 + feature contributions = -7.091 (log-odds).
Score = sigmoid(-7.091) = 0.001.
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. | 110 | −0.994 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 109.968 | +0.97 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.07 | +0.263 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 16 | −0.184 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 31 | −0.061 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 18 | +0.008 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 29.667 | +0.005 |
Intercept 0.07 + feature contributions = 0.076 (log-odds).
Score = sigmoid(0.076) = 0.519.
| Score | 0.242 |
|---|
| Score | 10 |
|---|
Run 1
The code demonstrates moderate readability. The hash computation is compact but uses bitwise operations that could benefit from named constants or helper functions. The binary search logic is fairly clear with descriptive variable names like search_low, search_high, and search_index. The goto statement is well-documented with justification for its presence. The comment explaining the backwards linear search is helpful. However, the code jumps between different logical sections without clear separation, and the hash computation relies on implicit endianness assumptions. The nesting is minimal and action granularity is reasonable, but the overall flow feels somewhat disjointed. The comments help clarify intent, though some technical debt is acknowledged (the commented-out alternative hash implementation).
Run 2
The code is difficult to follow due to unclear variable names, inconsistent formatting, and heavy reliance on comments to explain non-obvious logic. The binary manipulation on the first line is dense, and the use of a goto, despite the explanatory comment, disrupts natural reading flow. Nesting is minimal, but the logic is fragmented across comments and conditionals, making intent hard to grasp. Bitwise endian handling and manual loop adjustments are not self-documenting. While comments try to clarify, they also highlight the need for refactoring into clearer abstractions or helper functions. Overall, the structure is tangled and the reading flow is poor.
Run 3
The code is difficult to follow due to multiple factors. The bit-manipulation line packs several operations into one expression, violating action granularity and clarity of intent. The binary search adjustment logic is reasonably structured but its purpose is obscured by unclear variable names like 'hash_order_a' and 'hash_order_mem'. The goto statement, while documented, disrupts reading flow and requires the reader to jump to a label defined elsewhere. The commented-out code and endian note add context but also clutter. Nesting is relatively shallow, which is positive, but the overall structure mixes binary search logic, hash comparison, and linear backward traversal without clear separation. The final while loop condition is dense and combines index checking with array access, making it harder to parse. Code length is reasonable, but conciseness sometimes comes at the expense of clarity.
Run 1
Code Structure: Search-bound updates, match detection, and backward scanning form logical stages, but the partial loop and external goto target obscure the overall organization. Nesting: Visible control flow is shallow and easy to follow. Clarity of intent: Descriptive search variables and comments explain duplicate handling and index-underflow prevention; byte-order manipulation and the relationship between hash representations require interpretation. Code length: Executable code is concise, but verbose comments and a commented-out assignment add clutter. Action granularity: Most statements perform one action, although the byte-swapping expression packs several operations into one long line. Reading flow: The progression from searching to locating the first duplicate is mostly natural, but goto, missing surrounding context, and inconsistent formatting interrupt it.
Run 2
Code Structure: Search-bound updates and duplicate traversal form logical blocks, but the partial loop context and goto obscure overall control flow. Nesting: Shallow conditionals and a simple while loop are easy to follow. Clarity of intent: Comments explain matching hashes, backward traversal, and underflow avoidance, but cryptic names such as a and unexplained indexing reduce clarity. Code length: The executable code is concise, though verbose commentary and a commented-out assignment add clutter. Action granularity: Most statements perform one action, but the byte-reordering expression packs several operations into one dense line. Reading flow: Local progression is understandable, but the missing loop opening, external goto target, and inconsistent formatting interrupt a natural reading.
Run 3
Code Structure: Search-bound updates, match detection, and duplicate backtracking are logically grouped, but the goto and partial loop context complicate control flow. Nesting: The visible code is mostly flat, with shallow conditionals and a simple while loop. Clarity of intent: Descriptive search variables and comments explain the algorithm, but the dense byte-swapping expression, generic variable a, and magic constants obscure details. Code length: Executable code is reasonably concise, although lengthy comments and a commented-out assignment add clutter. Action granularity: Statements generally perform one action per line; the initial expression combines several bitwise operations into a visually dense statement. Reading flow: The search progresses naturally toward locating the first duplicate, but the goto, unexplained destination, and unmatched surrounding loop boundary interrupt local comprehension.