Sample
Schnappinger/jsweet/def.dom.ChildNode
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.493 | 0–1; higher is more readable | 78.3Δ 8.8 |
| Scalabrino | 0.999 | 0–1; higher is more readable | 100.0Δ 30.5 |
| Dorn | 0.713 | 0–1; higher is more readable | 76.6Δ 7.1 |
| Mi | 0.647 | 0–1; higher is more readable | 72.3Δ 2.8 |
| LLOC | 1 | Logical lines; fewer is more readable | 98.3Δ 28.9 |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs | 59.9Δ 9.6 |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs | 92.6Δ 23.1 |
| BTTF | 0.66 | 0–1; higher is more readable | 69.3Δ 0.2 |
| 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.687 | −7.03 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 129.324 | −4.268 |
| Source linesThe number of non-empty source lines. | 6 | +2.4 |
Intercept 8.87 + feature contributions = -0.028 (log-odds).
Score = sigmoid(-0.028) = 0.493.
| Score | 0.999 |
|---|
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. | 7 | +0.788 |
| 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. | 5.804 | −0.329 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.095 | +0.016 |
Intercept 0.07 + feature contributions = 0.911 (log-odds).
Score = sigmoid(0.911) = 0.713.
| Score | 0.647 |
|---|
| Score | 1 |
|---|
Run 1
The code is structurally clear and concise, with a single class definition and a native method. It maintains flat nesting (no nested blocks), clear intent (an interface-based abstraction of ChildNode with a remove method), and good reading flow. However, the score is reduced because the code is highly dependent on external annotations (@jsweet.lang.Interface, def.js.Object) which obscure intent to unfamiliar readers. Additionally, native method syntax is not self-explanatory without context. Action granularity is fine, and length is appropriate for the task, but overall readability suffers from framework-specific conventions.
Run 2
The code is highly readable. It is concise with a clear, logical structure: a simple abstract class with a single native method. There is no nesting, and intent is unambiguous. Action granularity and reading flow are natural, with one clear operation. Minor deductions only for lack of contextual documentation or annotations for non-domain readers.
Run 3
The code is a concise Java interface declaration using jsweet annotations. It has a clear single responsibility: defining a ChildNode contract with a remove method. Structure is minimal and logical, with no nesting or unnecessary length. The intent is explicit—expose a DOM-like node removal capability. Action granularity is one action per line. Reading flow is natural, starting from package, annotation, class declaration, and method. Minor deduction only because the annotation placement and abstract class usage might be slightly unclear to developers unfamiliar with jsweet, but overall readability is very high.
Run 1
Code Structure: A logically organized package, annotated class, and single method. Nesting: Minimal, with only one class body. Clarity of intent: ChildNode and remove() clearly communicate the DOM operation, though the abstract class/interface annotation combination requires JSweet knowledge. Code length: Concise, with no unnecessary implementation. Action granularity: Each declaration occupies its own line. Reading flow: Natural top-to-bottom progression; a blank line after the package declaration and conventional public native modifier order would slightly improve presentation.
Run 2
Code Structure: A simple, logically organized class containing one method. Nesting: Minimal, with no nested control flow. Clarity of intent: ChildNode and remove() communicate their purpose clearly, although the JSweet annotation and native declaration require framework knowledge. Code length: Concise, with no unnecessary code. Action granularity: Each declaration occupies its own line. Reading flow: Natural progression from package to annotation, class, and method; a blank line after the package declaration would slightly improve visual separation.
Run 3
Code Structure: The package, annotation, class, and method are logically organized. Nesting: Only a single class scope is present, making the code easy to scan. Clarity of intent: ChildNode and remove() clearly convey a DOM node removal operation, though the native abstract-class interface pattern requires familiarity with JSweet. Code length: The snippet is concise with no unnecessary implementation. Action granularity: Each declaration occupies its own line. Reading flow: The top-to-bottom order is natural; a blank line after the package declaration and conventional public native modifier ordering would slightly improve readability.