Sample
Schnappinger/junit4/org.junit.runner.JUnitCore
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 49.2Δ 2.2 |
| Scalabrino | 0.88 | 0–1; higher is more readable | 83.9Δ 32.6 |
| Dorn | 0.176 | 0–1; higher is more readable | 38.9Δ 12.4 |
| Mi | 0.189 | 0–1; higher is more readable | 15.2Δ 36.1 |
| LLOC | 40 | Logical lines; fewer is more readable | 43.2Δ 8.1 |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs | 83.0Δ 31.7 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 73.8Δ 22.4 |
| BTTF | 0.684 | 0–1; higher is more readable | 76.6Δ 25.2 |
| Human | 3.9 | 1–4; original rating | 51.3 |
Views
Loading feature diagnosis…
Source regions
Feature contributions
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. | 3123.769 | −103.084 |
| Source linesThe number of non-empty source lines. | 167 | +66.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.514 | −6.771 |
Intercept 8.87 + feature contributions = -34.186 (log-odds).
Score = sigmoid(-34.186) = 0.
| Score | 0.88 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 168 | −4.912 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 96 | +2.583 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 166.86 | +1.923 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 96 | −1.782 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 105.952 | +0.905 |
| 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. | 105.976 | −0.824 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.046 | +0.496 |
Intercept 0.07 + feature contributions = -1.54 (log-odds).
Score = sigmoid(-1.54) = 0.176.
| Score | 0.189 |
|---|
| Score | 40 |
|---|
Run 1
The code is well-structured with a clear facade pattern and logical method overloads. Each method has a single, clear responsibility and is accompanied by concise Javadoc. Nesting is minimal; the only notable block is the try/finally, which is appropriately flat. Intent is unambiguous throughout. The code is concise, with no unnecessary repetition aside from minor Javadoc duplication in method overloads. Action granularity is excellent — one action per line, with no multiple statements on a single line. Reading flow is natural, moving from public API entry points to internal execution logic. The only minor drawbacks are the slightly redundant Javadoc between overloaded runClasses methods and the field name prefix 'f', but these do not significantly impact readability.
Run 2
The code is highly readable. Structure is logical: public API methods are grouped, with overloads delegated cleanly. Nesting is minimal; the only try/finally block is clear and serves resource cleanup. Intent is well-documented with Javadoc explaining each method's purpose. Code length is concise—methods are short and avoid unnecessary verbosity. Each line performs one clear action, improving granularity. Reading flow is natural, progressing from entry points (main, runClasses) to internal execution (run(Runner)) and utility methods (defaultComputer). Field naming (fNotifier) follows a consistent convention. Overall, this is a clean façade design.
Run 3
The code is well-structured with clear separation of concerns, minimal nesting, and a logical flow from entry points to core execution. Each method has a single responsibility and uses concise delegation to avoid duplication. Javadoc comments enhance clarity of intent. Minor deductions due to slight repetition in overloaded run/runClasses methods and the field prefix 'f' (Hungarian notation), which slightly reduces readability for modern Java developers.
Run 1
Code Structure: Well-organized facade with small methods separating command-line execution, request conversion, test running, and listener management. Nesting: Minimal; only a straightforward try/finally block adds depth. Clarity of intent: Descriptive method names and extensive Javadoc explain most responsibilities, although the fNotifier naming convention and vague testing-only comment slightly reduce clarity. Code length: Implementations are concise, but repeated documentation and numerous overloads lengthen the class. Action granularity: Statements generally perform one clear action per line; delegation chains remain simple. Reading flow: Consistent formatting and progression from entry points to execution and listener helpers make navigation natural, though understanding overload delegation requires some jumping between methods.
Run 2
Code Structure: Well-organized facade with small methods separating command-line execution, test execution, and listener management. Nesting: Almost entirely flat; the single try/finally clearly expresses cleanup. Clarity of intent: Descriptive method names and extensive Javadoc explain most responsibilities, although fNotifier is dated naming and the testing-only run(Runner) documentation is limited. Code length: Implementations are concise, but repeated Javadoc and numerous delegating overloads increase reading volume. Action granularity: Statements generally perform one clear action per line; constructor and method chaining remain straightforward. Reading flow: Consistent formatting and progressively delegating run methods create a natural flow, though tracing execution requires moving through several overloads. Overall, highly readable with minor documentation and navigation overhead.
Run 3
Code Structure: Well-organized facade with small methods separating command-line execution, request construction, test execution, and listener management. Nesting: Almost entirely flat; the single try/finally clearly expresses listener cleanup. Clarity of intent: Descriptive method names and extensive Javadoc explain responsibilities, although the legacy fNotifier name and vague testing-only documentation slightly reduce clarity. Code length: Implementations are concise, but repeated Javadoc and numerous forwarding overloads add reading overhead. Action granularity: Statements generally perform one clear action per line; short chained calls remain understandable. Reading flow: Execution progresses naturally from entry points through delegating overloads to the central runner method, followed by listener helpers. Overall, the code is highly readable with minor documentation and naming distractions.