Sample
Schnappinger/jsweet/def.dom.HTMLNextIdElement
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.715 | 0–1; higher is more readable | 83.3Δ 38.1 |
| Scalabrino | 0.841 | 0–1; higher is more readable | 72.3Δ 27.0 |
| Dorn | 0.802 | 0–1; higher is more readable | 85.5Δ 40.3 |
| Mi | 0.655 | 0–1; higher is more readable | 74.3Δ 29.0 |
| LLOC | 3 | Logical lines; fewer is more readable | 91.1Δ 45.9 |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs | 73.9Δ 28.7 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 10.1 |
| BTTF | 0.674 | 0–1; higher is more readable | 73.6Δ 28.4 |
| Human | 3.84 | 1–4; original rating | 45.2 |
Views
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.69 | −7.036 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 112.588 | −3.715 |
| Source linesThe number of non-empty source lines. | 7 | +2.8 |
Intercept 8.87 + feature contributions = 0.919 (log-odds).
Score = sigmoid(0.919) = 0.715.
| Score | 0.841 |
|---|
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. | 51.875 | +1.468 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 8 | +0.753 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 6 | −0.53 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.06 | +0.36 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 6.717 | −0.316 |
Intercept 0.07 + feature contributions = 1.399 (log-odds).
Score = sigmoid(1.399) = 0.802.
| Score | 0.655 |
|---|
| Score | 3 |
|---|
Run 1
The code is highly readable due to its simplicity and clarity. It defines a class with a clear purpose (HTMLNextIdElement extending HTMLElement) and declares a public field, a static prototype, and a no-argument constructor. The structure is logical and flat, with no nesting or complex logic. Each declaration is on a single line, adhering to good action granularity. The naming is conventional and the intent is straightforward. The only minor deduction is due to the lack of comments or documentation, but for such a minimal class, none are needed. Overall, the reading flow is natural and the code is concise.
Run 2
The code is highly readable due to its simple, flat structure with no nesting and a clear single-purpose class definition. Intent is explicit: a DOM element subclass with a public field, a static prototype, and a default constructor. It is concise, with each declaration on its own line, following a natural top-to-bottom reading flow. Only minor deductions for lack of documentation or context, but overall it is clear and well-organized.
Run 3
The code is highly readable due to its simple, flat structure and clear intent. It defines a DOM element class with minimal fields and a constructor, making the purpose unambiguous. Nesting is nonexistent, and each line performs a single action, contributing to a natural reading flow. The code is concise, containing only essential declarations without unnecessary verbosity. The main drawback is the lack of Javadoc or comments explaining the purpose of 'n' and 'prototype', which slightly reduces clarity for unfamiliar readers. Overall, the structure is logical and straightforward, with no tangling or excessive length.
Run 1
Code Structure: The class is logically organized with fields followed by a constructor. Nesting: There is no deep nesting. Clarity of intent: The class name and inheritance indicate a DOM element binding, but the field name 'n' and the purpose of 'prototype' are unclear without context. Code length: The code is concise, with no unnecessary implementation. Action granularity: Each declaration occupies its own line. Reading flow: The order is natural, though blank lines between the package, class, fields, and constructor, plus spacing around the constructor braces, would improve readability.
Run 2
Code Structure: A straightforward class with logically grouped fields and a constructor. Nesting: Minimal, with no nested control flow. Clarity of intent: The class name and inheritance indicate a DOM element binding, but the field name 'n' is cryptic without context. Code length: Very concise, with no unnecessary code. Action granularity: Each declaration appears on its own line. Reading flow: Easy to follow, though blank lines between the package, class, fields, and constructor, plus conventional spacing in the empty constructor, would improve presentation.
Run 3
Code Structure: A straightforward class with logically grouped fields and a constructor. Nesting: Minimal, with no nested control flow. Clarity of intent: The class name and inheritance establish its DOM role, but the field name 'n' is opaque and 'prototype' lacks explanatory context. Code length: Concise, with no unnecessary code. Action granularity: Each declaration occupies its own line. Reading flow: Natural top-to-bottom organization, though blank lines between the package, fields, and constructor, plus conventional constructor spacing, would improve readability.