Sample

Schnappinger/junit4/org.junit.runner.FilterFactoryParams

Human rating uses the original dataset scale.

DatasetSchnappinger

Human3.95

Lines17

Scores

Method	Score	Scale	Dataset rank (0–100)
Posnett	0.625	0–1; higher is more readable	81.9Δ 12.5
Scalabrino	0.907	0–1; higher is more readable	90.4Δ 20.9
Dorn	0.835	0–1; higher is more readable	90.8Δ 21.3
Mi	0.716	0–1; higher is more readable	85.8Δ 16.3
LLOC	7	Logical lines; fewer is more readable	75.9Δ 6.4
DeepSeek V4 Pro	18	0–20; mean of three runs	91.4Δ 21.9
GPT-6.1 Sol	19	0–20; mean of three runs	92.6Δ 23.1
BTTF	0.781	0–1; higher is more readable	93.7Δ 24.3
Human	3.95	1–4; original rating	69.5

Views

Source code

package org.junit.runner; public final class FilterFactoryParams { private final String args; public FilterFactoryParams(String args) { if (args == null) { throw new NullPointerException(); } this.args = args; } public String getArgs() { return args; } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature	Value	Contribution (log-odds)
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.	266.274	−8.787
Source linesThe number of non-empty source lines.	17	+6.8
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.248	−6.371

Intercept 8.87 + feature contributions = 0.512 (log-odds).
Score = sigmoid(0.512) = 0.625.

Score	0.907

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.	44.944	+1.762
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.	17	+0.434
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.	16.826	−0.175
Indentation frequencyHow rapidly indentation changes from line to line.	17	−0.149
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.	0.088	+0.085

Intercept 0.07 + feature contributions = 1.62 (log-odds).
Score = sigmoid(1.62) = 0.835.

Score	0.716

Score	7

Run 1

The code is highly readable due to its clear structure and simplicity. It follows a standard class layout (fields, constructor, accessor) with no nesting or unnecessary complexity. Each action is on its own line, and the null check explicitly communicates intent. Minor improvements could include a descriptive exception message and making the argument name more specific (e.g., 'args' vs 'filterArgs').

Run 2

The code is highly readable. It is well-structured as a simple, final class with a clear single responsibility. There is no nesting beyond the single null-check, which is straightforward. The intent is unambiguous: store and provide access to filter arguments. The code is concise without being overly terse. Each line performs one clear action, from parameter validation to assignment and getter return. The reading flow is natural and logical, moving from class declaration to constructor logic to the getter. The only minor improvement could be a more descriptive exception message, but this does not detract from the overall clarity.

Run 3

The code is highly readable. It has a clear, logical structure with a single class and one field, showing flat nesting and no complexity. The intent is explicit: an immutable parameter holder, with validation against null. The code is concise, containing no unnecessary lines. Each action — validation and assignment — occurs on separate lines, aiding comprehension. The reading flow is natural, moving from field declaration to constructor logic and then to the accessor. Minor deductions could be made for the generic NullPointerException message and the slightly verbose single-purpose class, but overall it is a clean, well-organized example of simple Java code.

Run 1

Code Structure: A logically organized immutable class with a field, constructor, and getter. Nesting: Only one shallow conditional. Clarity of intent: Parameter storage and null rejection are clear, though 'args' does not describe the expected content and the exception lacks a message. Code length: Concise with no unnecessary logic. Action granularity: Each statement performs a single action on its own line. Reading flow: Conventional Java ordering and consistent formatting make the code easy to follow.

Run 2

Code Structure: Logically organized into a field, constructor, and accessor. Nesting: Minimal, with only a single-level null check. Clarity of intent: Clearly stores and exposes a non-null argument string, though 'args' is generic and the exception lacks a descriptive message. Code length: Concise, with no unnecessary logic. Action granularity: Each statement performs one action. Reading flow: Natural progression from state declaration to initialization and retrieval, supported by consistent formatting.

Run 3

Code Structure: A well-organized class with one immutable field, a constructor, and an accessor. Nesting: Minimal, with only a single null-check conditional. Clarity of intent: Clearly stores and exposes a non-null argument string, though the generic name 'args' provides limited domain context. Code length: Concise, with no unnecessary logic. Action granularity: Each statement performs one action. Reading flow: Natural progression from field declaration to initialization and retrieval, supported by consistent formatting. A descriptive exception message could make the null constraint slightly clearer.