Sample
Schnappinger/jsweet/def.dom.CSSConditionRule
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.764 | 0–1; higher is more readable | 84.3Δ 14.8 |
| Scalabrino | 0.853 | 0–1; higher is more readable | 76.7Δ 7.2 |
| Dorn | 0.788 | 0–1; higher is more readable | 82.5Δ 13.0 |
| Mi | 0.669 | 0–1; higher is more readable | 77.6Δ 8.1 |
| LLOC | 3 | Logical lines; fewer is more readable | 91.1Δ 21.6 |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs | 73.9Δ 4.5 |
| GPT-6.1 Sol | 18.33 | 0–20; mean of three runs | 85.3Δ 15.8 |
| BTTF | 0.665 | 0–1; higher is more readable | 71.0Δ 1.5 |
| Human | 3.95 | 1–4; original rating | 69.5 |
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.521 | −6.782 |
| 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 = 1.173 (log-odds).
Score = sigmoid(1.173) = 0.764.
| Score | 0.853 |
|---|
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. | 55 | +1.336 |
| 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 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.056 | +0.402 |
| 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. | 6.821 | −0.314 |
Intercept 0.07 + feature contributions = 1.31 (log-odds).
Score = sigmoid(1.31) = 0.788.
| Score | 0.669 |
|---|
| Score | 3 |
|---|
Run 1
The code is concise and clear. It defines a simple DOM class with a property, a prototype reference, and a constructor. Structure is logical, nesting is non-existent, intent is obvious, and length is minimal. Minor deductions for lack of comments or contextual documentation, but overall highly readable.
Run 2
The code is highly readable and clean. It follows a logical structure with package declaration, class definition, and members clearly organized. The nesting is completely flat, with no conditional blocks or methods creating complexity. The intent is very clear: to define a DOM interface extending CSSGroupingRule with a condition text property. The code is concise—only essential fields and a constructor are present. Each action appears on its own line, improving readability. The reading flow is natural: package first, then class declaration, public fields, and constructor. Minor deductions are for the empty constructor and missing documentation, but for a DOM interface definition, this is acceptable.
Run 3
The code is concise and clearly structured. It declares a class extending CSSGroupingRule with straightforward fields and a simple constructor. The naming is standard and intentional. There is no unnecessary nesting or verbosity, and each declaration occupies its own line, improving readability. Potential minor deduction is due to the public mutable field and the static prototype field, which could benefit from comments explaining their purpose in the DOM context, but overall the code is highly readable.
Run 1
Code Structure: A simple, logically organized class with fields followed by a constructor. Nesting: Minimal, with no nested control flow. Clarity of intent: The class name, superclass, and conditionText field clearly indicate a CSS condition rule, though the prototype field's role is not explained. Code length: Very concise, with no unnecessary logic. Action granularity: Each declaration occupies its own line. Reading flow: Natural and easy to follow, but blank lines between the package, class, fields, and constructor, along with spacing in the empty constructor, would improve readability.
Run 2
Code Structure: The package declaration and small class are logically organized, with related fields and a constructor grouped together. Nesting: There is no unnecessary nesting. Clarity of intent: The class name, superclass, and conditionText field clearly suggest a DOM CSS condition rule; the purpose of the static prototype field is less obvious 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 and easy to follow, although blank lines between the package, fields, and constructor, plus conventional spacing in the empty constructor, would improve presentation.
Run 3
Code Structure: A simple, logically organized class with fields followed by a constructor. Nesting: Minimal, with no nested control flow. Clarity of intent: The class name, superclass, and conditionText field clearly indicate a CSS condition rule; the purpose of the static prototype field is less explicit. Code length: Concise, with no unnecessary implementation. Action granularity: Each declaration occupies its own line. Reading flow: Natural from package declaration to class, fields, and constructor, though blank lines and conventional spacing around the empty constructor would improve visual readability.