Sample
Dorn/cuda/60
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.185 | 0–1; higher is more readable | 75.8Δ 18.7 |
| Scalabrino | 0.831 | 0–1; higher is more readable | 90.3Δ 33.2 |
| Dorn | 0.653 | 0–1; higher is more readable | 59.6Δ 2.5 |
| Mi | 0.7 | 0–1; higher is more readable | 83.8Δ 26.7 |
| LLOC | 13 | Logical lines; fewer is more readable | 50.8Δ 6.3 |
| DeepSeek V4 Pro | 7 | 0–20; mean of three runs | 22.7Δ 34.4 |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs | 41.4Δ 15.7 |
| BTTF | 0.502 | 0–1; higher is more readable | 45.7Δ 11.4 |
| Human | 3.41 | 1–5; original rating | 57.1 |
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. | 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.
| Score | 0.831 |
|---|
Feature contributions
| Feature | Value | Contribution (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.
| Score | 0.7 |
|---|
| Score | 13 |
|---|
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.