Sample

Dorn/cuda/60

Human rating uses the original dataset scale.

DatasetDorn
Human3.41
Lines30

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett0.1850–1; higher is more readable
75.8Δ 18.7
Scalabrino0.8310–1; higher is more readable
90.3Δ 33.2
Dorn0.6530–1; higher is more readable
59.6Δ 2.5
Mi0.70–1; higher is more readable
83.8Δ 26.7
LLOC13Logical lines; fewer is more readable
50.8Δ 6.3
DeepSeek V4 Pro70–20; mean of three runs
22.7Δ 34.4
GPT-6.1 Sol140–20; mean of three runs
41.4Δ 15.7
BTTF0.5020–1; higher is more readable
45.7Δ 11.4
Human3.411–5; original rating
57.1

Views

Download official ZIP ↗

Select the downloaded ZIP or its extracted folder. Files stay in your browser.

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.465.293−15.355
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.666−6.998

Intercept 8.87 + feature contributions = -1.483 (log-odds).
Score = sigmoid(-1.483) = 0.185.

Score0.831

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.85.806+0.58
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.047+0.481
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−0.359
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.31−0.061
Indentation frequencyHow rapidly indentation changes from line to line.20−0.045
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.20−0.038
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.29.792+0.007

Intercept 0.07 + feature contributions = 0.634 (log-odds).
Score = sigmoid(0.634) = 0.653.

Score0.7
Score13
Run 1

The code snippet has significant readability issues. The structure is fragmented, showing the tail end of one function before cutting to another without clear separation. The comment block preceding the function is overly long and contains a typo ('garuanteed'), adding noise. Variable naming is inconsistent and unclear ('inArgs', 'outArgs', 'sem_in', 'sem_out' lack descriptive context). The if-statement is properly flat, but the semaphore handling and response assignment happen in rapid succession without explanatory comments. The function appears to imply thread synchronization but the logic flow is disjointed from the reader's perspective. Several lines bundle related actions together, but the overall lack of contextual naming and abrupt transitions reduce clarity. The return statements and error handling in the first fragment are clear but disconnected from the handler function shown next.

Run 2

The code excerpt is difficult to evaluate in isolation but shows several readability issues. The structure is fragmented—starting mid-function with error handling and context cleanup, then transitioning to a thread handler without clear separation. Comments are verbose but helpful, though they interrupt flow. Nesting is minimal, but the action granularity is inconsistent: multiple operations appear on single lines in the handler (sem_post, sem_wait, assignments) without spacing or grouping. The intent is partially clear—initialization error handling and message passing—but the use of global state (inArgs, outArgs, semaphores) obscures the logic. Variable naming is terse and non-descriptive (msg_sz, respMsgSz). The reading flow jumps from error handling to initialization, then to a handler explanation, making it hard to follow without surrounding context. Overall, the code functions but lacks clarity, organization, and consistent formatting.

Run 3

The code snippet is difficult to evaluate fully as it is incomplete, beginning mid-function. Structure is fragmented, showing the tail of one function and the start of another. The second function mixes comment blocks with code and lacks clear separation between setup, signaling, and response handling. Nesting is shallow, which is good, but clarity of intent suffers due to incomplete variable declarations (inArgs, outArgs) and abrupt context. The code is concise but at the cost of explanation—lines like sem_post/sem_wait assume deep familiarity. Action granularity is acceptable, with one action per line. Reading flow is disrupted by misplaced comments and missing surrounding logic. Overall, it is borderline maintainable but not highly readable in its current form.

Run 1

Code Structure: The handler follows a logical sequence: validate input, pass the message, synchronize, and return response data. However, the excerpt starts mid-function and ends without a closing brace. Nesting: Minimal nesting and an early return make the handler easy to follow. Clarity of intent: Function and variable names communicate message forwarding, and comments explain threading concerns, but global state and semaphore behavior require external context. The comment also discusses manual context management not shown here. Code length: The executable code is concise, while the lengthy comment contains repetition and typos. Action granularity: Each statement performs one action on its own line. Reading flow: Operations proceed naturally, with blank lines separating stages, although inconsistent spacing and incomplete surrounding code reduce readability.

Run 2

Code Structure: The handler follows a logical sequence: validate input, pass arguments, synchronize, and return response data. However, the excerpt begins and ends mid-function, limiting structural readability. Nesting: Minimal nesting and an early return keep the handler flat. Clarity of intent: The function name and comments explain its role, but external state (inArgs, outArgs, and semaphores) requires additional context. The comment discusses context management that is not directly visible in the handler. Code length: The implementation is concise, though its lengthy comment contains repetition and typos. Action granularity: Each statement performs one action, making individual operations easy to identify. Reading flow: Execution proceeds naturally, with blank lines separating phases, but inconsistent spacing and the incomplete surrounding code interrupt the flow.

Run 3

Code Structure: The handler is logically organized into validation, input setup, synchronization, and response assignment, but the excerpt starts and ends mid-function. Nesting: Minimal nesting and an early return make the handler easy to scan. Clarity of intent: Descriptive function and semaphore names help, and the comment explains threading constraints; however, global dependencies are implicit, and the context-management discussion is not directly reflected in the shown handler. Code length: The implementation is concise, though the long introductory comment is repetitive and contains distracting typos. Action granularity: Each statement performs one action, making operations easy to distinguish. Reading flow: Execution follows a natural sequential order, but inconsistent spacing, the unbraced conditional, and incomplete surrounding code reduce polish and readability.