Source code
Official dataset source · Buse/76
Sample
Buse/76
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.595 | 0–1; higher is more readable | 67.7Δ 11.1 |
| Dorn | 0.405 | 0–1; higher is more readable | 25.3Δ 31.3 |
| Mi | 0.752 | 0–1; higher is more readable | 92.9Δ 36.4 |
| LLOC | 3 | Logical lines; fewer is more readable | 88.9Δ 32.3 |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs | 73.2Δ 16.7 |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs | 96.0Δ 39.4 |
| BTTF | 0.305 | 0–1; higher is more readable | 11.1Δ 45.5 |
| Human | 3.49 | 1–5; original rating | 56.6 |
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.174 | −6.262 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 127.999 | −4.224 |
| Source linesThe number of non-empty source lines. | 5 | +2 |
Intercept 8.87 + feature contributions = 0.384 (log-odds).
Score = sigmoid(0.384) = 0.595.
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. | 62.667 | +1.011 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.183 | −0.838 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 6 | +0.824 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| 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. | 4.875 | −0.342 |
Intercept 0.07 + feature contributions = -0.384 (log-odds).
Score = sigmoid(-0.384) = 0.405.
| Score | 0.752 |
|---|
| Score | 3 |
|---|
Run 1
The code is clear and concise, performing serialization of device information. It has a flat structure with no nesting and each line represents a single logical action. The intent is evident: write the driver class name, device name, and device-specific data. However, there is minor ambiguity about why the driver class name is saved and whether 'writeData' has side effects, and the reading flow is slightly abrupt without surrounding context.
Run 2
The code is concise and each line performs a distinct action, contributing to clear action granularity. The intent is fairly clear: serialize device class name, device name, then device-specific data. The structure is flat with no nesting, and the reading flow is natural and sequential. However, readability is slightly reduced by a lack of context (e.g., variable declarations, exception handling) and the subtle dependency on the Device class's writeData method, which could obscure the overall serialization logic. Overall, it is easy to follow but could benefit from a brief comment or surrounding context.
Run 3
The code is clear and concise, with each line performing a distinct action. The structure is logical: it serializes the driver class name, device name, then delegates to device-specific data writing. Nesting is non-existent, and the intent is obvious. Minor deductions: the leading blank line with whitespace is unnecessary, and there's no context (method signature, exception handling, variable declarations) to fully evaluate integration or null-safety. The code is highly readable as-is but would benefit from surrounding context.
Run 1
Code Structure: logically groups driver metadata, device name, and device data serialization. Nesting: entirely flat, with no control-flow nesting. Clarity of intent: serialization is clear, though the driver class-name method chain and writeData implementation require some context. Code length: concise, with no unnecessary statements. Action granularity: each line performs one serialization action. Reading flow: natural top-to-bottom order, with whitespace separating metadata from device-specific data.
Run 2
Code Structure: Logically groups device serialization into three sequential operations. Nesting: Flat, with no nested control flow. Clarity of intent: Clearly writes the driver class name, device name, and device data, although the serialization format and ordering requirements are implicit. Code length: Concise, with no unnecessary statements. Action granularity: Each statement performs one primary action; the chained getters in the first line remain easy to follow. Reading flow: Natural top-to-bottom progression, with whitespace separating metadata from device data.
Run 3
Code Structure: logically groups device serialization steps. Nesting: no nested control flow. Clarity of intent: clearly writes the driver class name, device name, and device data, though the serialization format is implicit. Code length: concise, with no unnecessary statements. Action granularity: each line performs one serialization action; the chained getters remain understandable. Reading flow: naturally progresses from identifying metadata to device-specific data, with whitespace separating the stages.