Source code
Official dataset source · Dorn/cuda/107
Sample
Dorn/cuda/107
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.623 | 0–1; higher is more readable | 83.3Δ 13.1 |
| Scalabrino | 0.826 | 0–1; higher is more readable | 88.8Δ 7.6 |
| Dorn | 0.865 | 0–1; higher is more readable | 90.5Δ 5.8 |
| Mi | 0.519 | 0–1; higher is more readable | 55.7Δ 40.7 |
| LLOC | 6 | Logical lines; fewer is more readable | 72.8Δ 23.5 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 87.9Δ 8.5 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 93.5Δ 2.9 |
| BTTF | 0.568 | 0–1; higher is more readable | 65.7Δ 30.6 |
| Human | 4.16 | 1–5; original rating | 96.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) |
|---|---|---|
| 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.76 | −7.139 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 158.457 | −5.229 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
Intercept 8.87 + feature contributions = 0.502 (log-odds).
Score = sigmoid(0.502) = 0.623.
| Score | 0.826 |
|---|
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. | 54.909 | +1.34 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 11 | +0.647 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 5 | −0.564 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 9.607 | −0.276 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.081 | +0.158 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 54.909 | +0.082 |
Intercept 0.07 + feature contributions = 1.854 (log-odds).
Score = sigmoid(1.854) = 0.865.
| Score | 0.519 |
|---|
| Score | 6 |
|---|
Run 1
The code is well-structured and readable. It has a clear purpose: printing scoring parameters and initializing data. Actions are separated logically, one per line for the printf statements. Formatting is consistent with aligned output values. The comments clearly indicate the next steps. However, the nested function call `params->getMatrix(matrix)` slightly reduces clarity due to the pointer dereference. Overall, the code is concise, flat, and easy to follow.
Run 2
The code is generally readable with clear separation of steps and comments. Structure is logical but context around `params` and `mat` is missing. Nesting is minimal. Intent is mostly clear through comments and self-explanatory function names like `loaddb`. Length is concise. One statement per line respects action granularity. Reading flow is natural, though mixing output formatting and logic slightly disrupts flow.
Run 3
The code is highly readable with clear intent, flat structure, and concise length. Each line performs one action. The comments separate logical sections (scoring output, matrix loading, database loading), and the printf statements are aligned for easy scanning. The only minor deductions are for slight repetition in the printf alignment and the use of 'mat' instead of a more descriptive variable name, but overall it is straightforward and maintainable.
Run 1
Code Structure: Logically organized into parameter reporting, substitution-matrix loading, and database loading, with blank lines separating stages. Nesting: Completely flat and easy to follow. Clarity of intent: Descriptive output labels and brief comments communicate purpose, though the distinction between mat and matrix is not explicit. Code length: Concise, with no unnecessary logic; the decorative separator adds minor visual clutter. Action granularity: Each statement performs one action on its own line. Reading flow: Natural top-to-bottom progression, slightly weakened by inconsistent naming conventions, comment spacing, and the extra space before the getMatrix argument list.
Run 2
Code Structure: logically groups parameter output, matrix loading, and database loading with whitespace and comments. Nesting: completely flat and easy to follow. Clarity of intent: descriptive names and comments communicate the main purpose, though the relationship between mat and matrix and the behavior of getMatrix are not fully clear. Code length: concise, with no unnecessary complexity. Action granularity: each statement performs one action on its own line. Reading flow: straightforward sequential execution; minor inconsistencies in spacing and comment style slightly reduce polish.
Run 3
Code Structure: Logically organized into parameter reporting, matrix loading, and database loading. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive output labels and comments make the purpose clear, although the relationship between mat and matrix is not explicit. Code length: Concise, with little unnecessary code beyond a decorative separator. Action granularity: Each statement performs one action on its own line. Reading flow: Natural top-to-bottom progression, aided by blank lines; inconsistent spacing in getMatrix (matrix) and terse naming in loaddb slightly reduce polish.