Sample

Schnappinger/junit4/org.junit.experimental.max.CouldNotReadCoreException

Human rating uses the original dataset scale.

DatasetSchnappinger

Human3.95

Lines15

Scores

Method	Score	Scale	Dataset rank (0–100)
Posnett	0.895	0–1; higher is more readable	87.0Δ 17.5
Scalabrino	0.908	0–1; higher is more readable	91.4Δ 22.0
Dorn	0.877	0–1; higher is more readable	95.0Δ 25.6
Mi	0.6	0–1; higher is more readable	63.4Δ 6.1
LLOC	2	Logical lines; fewer is more readable	94.6Δ 25.1
DeepSeek V4 Pro	18.33	0–20; mean of three runs	96.0Δ 26.6
GPT-6.1 Sol	19	0–20; mean of three runs	92.6Δ 23.1
BTTF	0.794	0–1; higher is more readable	95.4Δ 25.9
Human	3.95	1–4; original rating	69.5

Views

Source code

package org.junit.experimental.max; /** * Thrown when Max cannot read the MaxCore serialization */ public class CouldNotReadCoreException extends Exception { private static final long serialVersionUID = 1L; /** * Constructs */ public CouldNotReadCoreException(Throwable e) { super(e); } }

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.659	−6.989
Source linesThe number of non-empty source lines.	15	+6
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.	173.916	−5.739

Intercept 8.87 + feature contributions = 2.142 (log-odds).
Score = sigmoid(2.142) = 0.895.

Score	0.908

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.	58	+1.209
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.	0.047	+0.481
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.	16	+0.47
Indentation frequencyHow rapidly indentation changes from line to line.	11	−0.357
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.	14.712	−0.204
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.	11	+0.168
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.	57.938	+0.13

Intercept 0.07 + feature contributions = 1.967 (log-odds).
Score = sigmoid(1.967) = 0.877.

Score	0.6

Score	2

Run 1

The code is highly readable. It has a clear, logical structure with package and import (though not visible), a simple class definition, and minimal members. Nesting is non-existent. The intent is immediately clear: a custom exception for MaxCore serialization failures. The code is concise, with no unnecessary methods or fields. Action granularity is one action per line, and the reading flow is natural, starting with Javadoc, class declaration, serialVersionUID, and constructor.

Run 2

The code is highly readable with a clear, single responsibility. The package structure and class name clearly communicate intent. Nesting is minimal—just a single class with a constructor. The constructor is concise, delegating to the superclass with proper exception chaining. The serialVersionUID is appropriately included. Documentation is brief and helpful. One minor deduction: the constructor Javadoc could be slightly more descriptive, but overall the code is well-structured, flat, and follows standard Java conventions.

Run 3

The code is highly readable. It follows standard Java conventions for a simple exception class. Structure is clear: package declaration, imports (none needed), Javadoc comment, class declaration, serialVersionUID, and constructor. Nesting is non-existent. Intent is explicit—communicating a failure to read the MaxCore serialization—via the class name, Javadoc, and constructor parameter. Length is minimal and appropriate; no redundant code. Each action (class declaration, field declaration, constructor call) is on its own line. Reading flow is natural: documentation first, then boilerplate, then constructor. Minor opportunity for improvement is the slightly vague 'Constructs' Javadoc, but overall this is nearly ideal.

Run 1

Code Structure: A well-organized exception class with a serialization identifier and constructor. Nesting: Minimal, with no nested control flow. Clarity of intent: The class name and class-level documentation clearly explain its purpose, though the constructor comment is uninformative and the parameter name 'e' could be more descriptive. Code length: Concise with no unnecessary implementation. Action granularity: Each declaration and statement occupies its own line. Reading flow: Conventional Java ordering and clean formatting make the code easy to follow.

Run 2

Code Structure: A well-organized exception class with a serialization identifier and constructor. Nesting: Minimal, with no nested control flow. Clarity of intent: The class name and class-level documentation clearly explain its purpose, though the parameter name 'e' and constructor comment 'Constructs' could be more descriptive. Code length: Concise, with no unnecessary implementation. Action granularity: Each declaration and operation occupies its own line. Reading flow: Natural Java ordering and consistent formatting make the code easy to follow.

Run 3

Code Structure: Logically organized exception class with a serialization identifier and constructor. Nesting: Minimal, limited to the class and constructor. Clarity of intent: The descriptive class name and class documentation clearly explain its purpose, though the parameter name 'e' and constructor comment 'Constructs' provide little detail. Code length: Concise, with no unnecessary implementation. Action granularity: Each declaration or action occupies its own line. Reading flow: Natural Java ordering and consistent formatting make the code easy to follow.