Sample

Schnappinger/jsweet/def.dom.GamepadEvent

Human rating uses the original dataset scale.

DatasetSchnappinger

Human3.95

Lines7

Scores

Method	Score	Scale	Dataset rank (0–100)
Posnett	0.792	0–1; higher is more readable	85.6Δ 16.1
Scalabrino	0.901	0–1; higher is more readable	89.6Δ 20.1
Dorn	0.859	0–1; higher is more readable	94.1Δ 24.6
Mi	0.687	0–1; higher is more readable	80.5Δ 11.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	0–20; mean of three runs	73.8Δ 4.3
BTTF	0.683	0–1; higher is more readable	75.2Δ 5.8
Human	3.95	1–4; original rating	69.5

Views

Source code

package def.dom; public class GamepadEvent extends Event { public Gamepad gamepad; public static GamepadEvent prototype; public GamepadEvent(){} }

Loading feature diagnosis…

Source regions

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.414	−6.62
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.334 (log-odds).
Score = sigmoid(1.334) = 0.792.

Score	0.901

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.	41	+1.929
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
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.	6.81	−0.315
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.	0.065	+0.307

Intercept 0.07 + feature contributions = 1.808 (log-odds).
Score = sigmoid(1.808) = 0.859.

Score	0.687

Score	3

Run 1

The code is concise and logically structured. It clearly declares a `GamepadEvent` class that extends `Event`, with a public `gamepad` field, a static `prototype` reference, and an empty constructor. The class structure is flat with no nesting, and the intent is clear. However, the empty constructor and undeclared initialization of `gamepad` reduce readability slightly, and the presence of `prototype` without context feels unusual. Overall, it is easy to understand but could be improved with constructor initialization and documentation.

Run 2

The code is highly readable. It has a clear, flat structure with a simple class definition. Intent is obvious: defining a GamepadEvent extending Event with a gamepad field and prototype. Length is minimal and appropriate. Each declaration occupies its own line, preserving action granularity. Reading flow is natural—package, class, fields, constructor—matching standard Java conventions. Minor deductions only because constructor and prototype lack explicit documentation or modifiers, leaving slight ambiguity about intended usage.

Run 3

The code is a simple, clean class definition with clear intent. It has a flat structure with no nesting, and each property declaration occupies its own line, adhering to one-action-per-line. The class name and property names are self-explanatory, and the package declaration provides proper organization. The reading flow is natural: package, class, properties, constructor. It is concise without being overly brief. Minor deductions could be made for lack of access modifiers (public properties are explicit, but the class members could benefit from comments or documentation), but this does not significantly harm readability. Overall, the code is highly readable and maintainable for its purpose.

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: Class inheritance and descriptive field types clearly indicate a gamepad event, though the static prototype field is unexplained. Code length: Concise, with no unnecessary implementation. Action granularity: Each declaration occupies its own line. Reading flow: Easy to follow, but missing blank lines and tight constructor formatting slightly reduce readability.

Run 2

Code Structure: The package declaration and small class provide a straightforward, logical organization. Nesting: Only the class and empty constructor are nested, keeping complexity minimal. Clarity of intent: The class name, Event inheritance, and gamepad field clearly indicate a gamepad-related event; the purpose of the static prototype field is less explicit. Code length: The code is concise with no unnecessary implementation. Action granularity: Each declaration occupies its own line. Reading flow: The sequence from package to class, fields, and constructor is natural, though blank lines between sections and spaces in the empty constructor would improve formatting.

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, Event inheritance, and gamepad field clearly indicate its purpose; the static prototype field is less self-explanatory. Code length: Very concise, with no unnecessary code. Action granularity: Each declaration occupies its own line. Reading flow: Natural package-to-class-to-members progression, though blank lines and spacing around the empty constructor would improve visual readability.