Sample
Schnappinger/junit4/org.junit.runner.Description
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 31.8Δ 62.0 |
| Scalabrino | 0.803 | 0–1; higher is more readable | 63.0Δ 30.7 |
| Dorn | 0.025 | 0–1; higher is more readable | 24.1Δ 69.6 |
| Mi | 0.269 | 0–1; higher is more readable | 18.2Δ 75.6 |
| LLOC | 89 | Logical lines; fewer is more readable | 26.9Δ 66.8 |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs | 66.8Δ 26.9 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 38.4 |
| BTTF | 0.546 | 0–1; higher is more readable | 49.2Δ 44.6 |
| Human | 4 | 1–4; original rating | 93.7 |
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. | 6994.788 | −230.828 |
| Source linesThe number of non-empty source lines. | 311 | +124.4 |
| 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.613 | −6.92 |
Intercept 8.87 + feature contributions = -104.478 (log-odds).
Score = sigmoid(-104.478) = 0.
| Score | 0.803 |
|---|
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. | 311 | −9.975 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 202 | +6.25 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 201 | −4.191 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 309.882 | +3.922 |
| 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.971 | −1.332 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 117.942 | +1.098 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.045 | +0.502 |
Intercept 0.07 + feature contributions = -3.656 (log-odds).
Score = sigmoid(-3.656) = 0.025.
| Score | 0.269 |
|---|
| Score | 89 |
|---|
Run 1
The code is generally well-structured and readable. It uses clear naming conventions, logical grouping of static factory methods, and concise helper methods like formatDisplayName and methodAndClassNamePatternGroupOrDefault. Nesting is minimal, and most methods are short and focused with a single responsibility. The Javadoc comments are thorough and explain intent well. However, readability is slightly reduced by the use of legacy 'f' field prefixes (e.g., fChildren, fDisplayName), inconsistent parameter ordering across factory methods, and some redundancy in overloaded createTestDescription and createSuiteDescription methods. The equals method lacks an instanceof symmetry check for subclasses but is acceptable. Overall, the code is easy to follow and maintain, but minor style inconsistencies and verbose factory overloads prevent a higher score.
Run 2
The code is highly readable and well-structured. It has a clear, logical organization with all factory methods grouped together, followed by constructors, then public methods, and finally private helpers. Nesting is minimal — the deepest logic appears in getTestClass and testCount, but remains shallow and easy to follow. Intent is clearly expressed through descriptive method names and comprehensive Javadoc, reflecting the expectations of a mature library like JUnit. Code length is appropriate given the API surface and backward-compatibility requirements, with no unnecessary repetition beyond intentional overloads. Action granularity is consistently one action per line, aiding comprehension. Reading flow is natural: static factories first, then instance methods in order of utility. Minor deductions include the concise but less-descriptive field naming convention (f-prefix) and some methods with conditional/logic chains, but these are trivial and idiomatic to the codebase.
Run 3
The code is highly readable and well-structured. It uses a clear class layout with related fields grouped, and methods are logically ordered. Nesting is minimal; conditionals and loops are shallow. Each method has a clear purpose, and naming is descriptive (e.g., fChildren, formatDisplayName). The code length is appropriate—concise while retaining necessary documentation. Action granularity is consistent, with one operation per line in most cases. Reading flow is natural, aided by Javadoc comments that explain intent without being verbose. Minor deductions: some naming conventions (e.g., f-prefixed fields) may feel outdated, and the methodAndClassNamePatternGroupOrDefault method is slightly awkward in naming but still clear. Overall, it is production-quality and easy to follow.
Run 1
1. Code Structure: Well-organized factory methods, constructors, accessors, and helpers; constants and fields appearing midway slightly weaken organization. 2. Nesting: Mostly flat, with early returns and only shallow loop/conditional nesting. 3. Clarity of intent: Descriptive method names and extensive documentation explain the API well; regex group numbers, abbreviated variables, and implicit display-name parsing require extra interpretation. 4. Code length: Individual methods are concise, but repeated factory overloads and lengthy, repetitive Javadocs increase scanning effort. 5. Action granularity: Statements generally perform one action per line; constructor calls and ternary expressions remain manageable. 6. Reading flow: Consistent formatting and small methods support natural reading, though scattered declarations, long lines, and switching between factory methods and instance behavior introduce minor interruptions.
Run 2
Code Structure: Factory methods, constructors, accessors, and helpers are mostly logically grouped, although constants and fields appear after several methods. Nesting: Shallow conditionals, early returns, and simple loops keep control flow easy to follow. Clarity of intent: Descriptive method names and extensive documentation explain the test-description model; legacy field prefixes, numeric regex group references, and implicit display-name parsing slightly obscure details. Code length: Individual methods are concise, but repeated factory overloads and verbose Javadocs increase overall length. Action granularity: Statements generally perform one action per line, with only straightforward expressions combining operations. Reading flow: Consistent formatting and delegation support natural reading, though scattered suite factories, long signatures, and occasional awkward documentation interrupt it. Overall, the code is highly readable with minor organizational and verbosity issues.
Run 3
Code Structure: Factory methods, constructors, accessors, and behavioral methods are logically grouped, although constants and fields interrupt the factory section. Nesting: Mostly flat methods with early returns; loops and conditionals remain shallow. Clarity of intent: Descriptive method names and extensive documentation explain the API well, but numeric regex groups, legacy field prefixes, and subtle identity and class-loading behavior require extra attention. Code length: Individual methods are concise, though repetitive factory overloads and lengthy, sometimes outdated documentation increase scanning effort. Action granularity: Statements generally perform one action per line, with compact expressions remaining understandable. Reading flow: Consistent formatting and small methods support natural reading, but scattered declarations, repetitive comments, and occasional long signatures slightly disrupt flow.