Sample
Schnappinger/junit4/org.junit.experimental.theories.Theories
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 20.1Δ 14.1 |
| Scalabrino | 0.656 | 0–1; higher is more readable | 29.5Δ 23.5 |
| Dorn | 0.096 | 0–1; higher is more readable | 32.3Δ 26.4 |
| Mi | 0.029 | 0–1; higher is more readable | 4.0Δ 2.0 |
| LLOC | 110 | Logical lines; fewer is more readable | 22.1Δ 16.2 |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs | 29.9Δ 23.9 |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs | 25.7Δ 19.8 |
| BTTF | 0.291 | 0–1; higher is more readable | 19.8Δ 13.9 |
| Human | 2.01 | 1–4; original rating | 5.9 |
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. | 10713.552 | −353.547 |
| Source linesThe number of non-empty source lines. | 255 | +102 |
| 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.289 | −6.434 |
Intercept 8.87 + feature contributions = -249.111 (log-odds).
Score = sigmoid(-249.111) = 0.
| Score | 0.656 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 253 | +8.014 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 255 | −7.992 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 253 | −5.385 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 254.95 | +3.154 |
| 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. | 117.949 | −1.331 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 118 | +1.099 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.083 | +0.131 |
Intercept 0.07 + feature contributions = -2.24 (log-odds).
Score = sigmoid(-2.24) = 0.096.
| Score | 0.029 |
|---|
| Score | 110 |
|---|
Run 1
The code is generally well-structured with clear method separation and purpose. It uses flat control flow in most places and maintains reasonable action granularity. However, readability is reduced by some long lines (especially validation error messages), redundant checks in validateDataPointFields/Methods, and the nested anonymous class inside TheoryAnchor.runWithCompleteAssignment which creates a complex reading flow. The TheoryAnchor inner class has somewhat unclear field naming (prefix 'f') and mixed responsibility, but overall intent is understandable. Some methods like computeTestMethods use non-obvious reordering logic that could benefit from a comment.
Run 2
The code has clear method names and logical separation of validation concerns, but it suffers from readability issues. The `TheoryAnchor` inner class creates an anonymous `BlockJUnit4ClassRunner` inside `runWithCompleteAssignment`, adding deep nesting and making the flow hard to follow. The `evaluate` method contains nested anonymous `Statement` classes that obscure the control flow. Several methods break the single-responsibility principle (`runWithCompleteAssignment` does too much), and some lines are overly long. The validation methods for DataPoint fields and methods are repetitive, violating DRY principles. While basic structure and naming are good, the complex nested callbacks and anonymous classes hurt clarity.
Run 3
The code has a logical structure with clear method separation, but suffers from several readability issues. The nesting in `runWithCompleteAssignment` is deep (4-5 levels), making it hard to follow the flow. The anonymous inner classes add complexity and obscure intent. Some methods like `validateParameterSupplier` are clear, while others mix validation and execution concerns. The action granularity is generally good - one operation per line - but long method signatures and chained calls reduce readability. Variable names like `fTestMethod` and `fInvalidParameters` use outdated Hungarian notation. The reading flow is disrupted by the deeply nested anonymous classes and scattered validation logic. While the code is maintainable, it requires careful reading to understand the theory testing mechanism, particularly the anonymous `BlockJUnit4ClassRunner` instantiation.
Run 1
Code Structure: Validation and execution responsibilities are separated into well-named methods, although the nested runner mixes orchestration, construction, and exception handling. Nesting: Most methods are shallow, but anonymous runner and Statement classes create substantial nesting in runWithCompleteAssignment. Clarity of intent: Descriptive method names and explicit exception handling communicate purpose; legacy f-prefixed fields and the awkward constructor-parameter condition reduce clarity. Code length: Generally justified, though field/method validation duplicates logic and anonymous-class boilerplate adds bulk. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Validation precedes execution in a logical order, and assignment handling is cleanly decomposed; inconsistent line wrapping, chained anonymous-class execution, and framework callbacks make the execution path harder to trace.
Run 2
Code Structure: Validation and execution responsibilities are organized into focused methods and a dedicated nested class, though anonymous runner customization adds complexity. Nesting: Most methods are shallow, but nested anonymous classes, overrides, and exception handling make runWithCompleteAssignment harder to follow. Clarity of intent: Descriptive method names and explicit error messages communicate purpose well; legacy f-prefixed fields and the negated constructor condition reduce clarity. Code length: Generally proportionate to functionality, although field/method validation duplicates logic and anonymous-class boilerplate adds verbosity. Action granularity: Statements generally perform one action per line, with only a few chained expressions demanding extra attention. Reading flow: Validation proceeds naturally into execution, and helper methods support navigation. However, inconsistent line wrapping, recursive assignment processing, and transitions between runner and statement contexts interrupt the flow and require familiarity with JUnit internals.
Run 3
Code Structure: Well-separated validation and execution methods provide logical organization, though the large inner class and anonymous runner concentrate complexity. Nesting: Most validation is shallow, but nested anonymous classes, overrides, and exception handling make execution harder to follow. Clarity of intent: Descriptive method names and explicit error messages communicate purpose; legacy f-prefixed fields and the awkward constructor-condition expression reduce clarity. Code length: Generally justified, but duplicated field/method validation and verbose anonymous classes add bulk. Action granularity: Statements usually perform one action per line, with clearly separated checks and updates. Reading flow: Validation progresses naturally into test discovery and execution, but recursive assignment processing, overridden runner behavior, and inconsistent line wrapping interrupt the flow.