Sample
Human rating uses the original dataset scale.
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.799 | 0–1; higher is more readable | 86.3Δ 35.0 |
| Scalabrino | 0.888 | 0–1; higher is more readable | 85.6Δ 34.3 |
| Dorn | 0.73 | 0–1; higher is more readable | 77.2Δ 25.9 |
| Mi | 0.891 | 0–1; higher is more readable | 100.0Δ 48.7 |
| LLOC | 3 | Logical lines; fewer is more readable | 91.1Δ 39.8 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 53.1Δ 1.8 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 73.8Δ 22.4 |
| BTTF | 0.693 | 0–1; higher is more readable | 79.2Δ 27.9 |
| Human | 3.9 | 1–4; original rating | 51.3 |
Loading feature diagnosis…
| 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.711 | −7.067 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 133.98 | −4.421 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
Intercept 8.87 + feature contributions = 1.382 (log-odds).
Score = sigmoid(1.382) = 0.799.
| Score | 0.888 |
|---|
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 11 | +0.647 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.045 | +0.504 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 7 | −0.495 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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. | 77.909 | +0.365 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 9.835 | −0.272 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 36.091 | −0.222 |
Intercept 0.07 + feature contributions = 0.994 (log-odds).
Score = sigmoid(0.994) = 0.73.
| Score | 0.891 |
|---|
| Score | 3 |
|---|
The code is well-structured with a clear package declaration, straightforward class inheritance, and a single public field. However, clarity of intent is impacted by the use of the wrapper type 'java.lang.Boolean' instead of the primitive 'boolean', and the field lacks an explicit access modifier. The empty constructor and static prototype field are present but not explained. The code is concise and flat with no nesting, and actions are separated appropriately. Reading flow is natural since it mirrors typical DOM interface definitions, though the naming style is not idiomatic Java (using 'noWrap' instead of 'noWrap' is correct, but 'prototype' is unusual). Overall, it is readable but would benefit from documentation or stronger typing conventions.
The code is concise and readable, with clear intent. It defines an HTMLDTElement class with a documented property, a static prototype, and an empty constructor. The structure is logically organized and flat, with no nesting or multiple actions per line. The JSDoc comment aids clarity. Minor deductions: the constructor adds little value, the package/class separation is minimal, and the code could be slightly more complete in terms of formatting conventions (e.g., blank lines), but overall it's straightforward and easy to understand.
The code demonstrates excellent readability. It is short, flat, and logically organized, with a clear class inheritance structure. The single field with its JSDoc comment clearly indicates intent. Each declaration is on its own line, maintaining action granularity. The code is concise and follows standard Java/TypeScript documentation conventions, creating a natural reading flow.
Code Structure: The package, class, fields, and constructor are logically organized. Nesting: Only a single class scope, making the code easy to scan. Clarity of intent: The class name and inheritance identify its DOM role, and the comment explains noWrap, though prototype is undocumented. Code length: Short and free of unnecessary logic. Action granularity: Each declaration occupies its own line. Reading flow: Natural top-to-bottom order, but missing blank lines between sections and the tightly formatted empty constructor slightly reduce readability.
Code Structure: A straightforward class declaration with logically grouped members. Nesting: Minimal nesting, limited to the class and empty constructor. Clarity of intent: Inheritance and the noWrap documentation clarify the purpose, though prototype lacks explanation and the comment describes word wrapping while the field name expresses its negation. Code length: Concise, with no unnecessary logic. Action granularity: Each declaration occupies its own line. Reading flow: Easy to follow, but missing blank lines between members and cramped constructor formatting slightly reduce readability.
Code Structure: The package declaration and small class are logically organized. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name, superclass, and documentation clearly indicate a DOM element representation, though noWrap is documented in terms of word wrapping without explicitly explaining its inverse meaning, and prototype is undocumented. Code length: Concise, with no unnecessary logic. Action granularity: Each declaration occupies its own line. Reading flow: Natural progression from package to class, fields, and constructor; missing spacing and the compact empty constructor slightly reduce readability.