Sample

Schnappinger/jsweet/def.dom.ChildNode

Human rating uses the original dataset scale.

Human3.95
Lines6

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett0.4930–1; higher is more readable
78.3Δ 8.8
Scalabrino0.9990–1; higher is more readable
100.0Δ 30.5
Dorn0.7130–1; higher is more readable
76.6Δ 7.1
Mi0.6470–1; higher is more readable
72.3Δ 2.8
LLOC1Logical lines; fewer is more readable
98.3Δ 28.9
DeepSeek V4 Pro16.670–20; mean of three runs
59.9Δ 9.6
GPT-6.1 Sol190–20; mean of three runs
92.6Δ 23.1
BTTF0.660–1; higher is more readable
69.3Δ 0.2
Human3.951–4; original rating
69.5

Views

Source code

package def.dom; @jsweet.lang.Interface public abstract class ChildNode extends def.js.Object { native public void remove(); }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.

Score0.999

Feature contributions

FeatureValueContribution
(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.

Score0.647
Score1
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.