Sample
Schnappinger/junit4/org.junit.experimental.theories.ParameterSignature
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 26.4Δ 62.7 |
| Scalabrino | 0.542 | 0–1; higher is more readable | 12.3Δ 76.8 |
| Dorn | 0.077 | 0–1; higher is more readable | 31.0Δ 58.1 |
| Mi | 0.472 | 0–1; higher is more readable | 30.0Δ 59.1 |
| LLOC | 65 | Logical lines; fewer is more readable | 33.2Δ 55.9 |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs | 59.9Δ 29.2 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 33.8 |
| BTTF | 0.248 | 0–1; higher is more readable | 16.2Δ 72.9 |
| Human | 4 | 1–4; original rating | 89.1 |
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. | 6084.922 | −200.802 |
| Source linesThe number of non-empty source lines. | 134 | +53.6 |
| 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.585 | −6.877 |
Intercept 8.87 + feature contributions = -145.209 (log-odds).
Score = sigmoid(-145.209) = 0.
| Score | 0.542 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 133 | +3.863 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 134 | −3.708 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 134 | −2.654 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 132.861 | +1.447 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| 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. | 99.955 | −0.568 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.11 | −0.127 |
Intercept 0.07 + feature contributions = -2.482 (log-odds).
Score = sigmoid(-2.482) = 0.077.
| Score | 0.472 |
|---|
| Score | 65 |
|---|
Run 1
The code is well-structured into a single cohesive class with clear responsibilities. Each method has a single purpose and names are descriptive. Nesting is minimal, with only a few levels in loops and conditionals, and helper methods like putSymmetrically and isAssignableViaTypeConversion keep the logic flat. Intent is clear: the class describes parameter signatures and type compatibility. Lines are concise, though a few multi-statement lines (e.g., return statements with ternary) slightly reduce readability. Action granularity is mostly one action per line, aside from a couple of wrapped method chains. Reading flow is natural, with methods logically grouped: type mapping, constructors, acceptance checks, and annotation utilities. Some small improvements could be made (e.g., avoiding the redundant annotations2 variable in findDeepAnnotation, and simplifying the ternary in canAcceptValue), but overall the code is highly readable.
Run 2
The code is well-structured into logical sections: type conversion map setup, factory methods, and annotation handling. Nesting is minimal, with only the recursive `findDeepAnnotation` reaching depth 3, which is acceptable. The intent is clear throughout — class names, method names, and constants like `CONVERTABLE_TYPES_MAP` express purpose well. Code length is appropriate; methods are short and focused, with no unnecessary duplication. Action granularity is mostly one action per line, and the helper `putSymmetrically` improves readability. Reading flow is natural: static initialization first, public factories next, then instance behavior. Minor drawbacks: generic method parameters like `<T> void putSymmetrically` could be clearer, and `signatures` overloads returning different types (`ArrayList` vs `List`) slightly obscure intent. Overall highly readable.
Run 3
The code is well-structured with clear separation of concerns, logical method ordering, and consistent naming conventions. It uses a flat hierarchy with minimal nesting—only the recursive annotation search introduces moderate depth. Most methods are concise and single-purpose, though `canPotentiallyAcceptType` chains three conditions on one line, slightly reducing clarity. Action granularity is generally good, with one operation per line, but the ternary in `canAcceptValue` and combined boolean logic in `canAcceptType` could be split for readability. The reading flow is natural, with public API methods followed by private helpers. The `findDeepAnnotation` recursion with depth parameter is slightly complex but documented by naming. Overall, the code is maintainable and readable, with only minor opportunities for improvement in reducing compound conditions.
Run 1
Code Structure: Well-organized, focused class with small helpers separating signature creation, type compatibility, and annotation lookup. Nesting: Mostly flat; annotation traversal has modest loop/conditional nesting and understandable recursion. Clarity of intent: Method names generally communicate purpose, but the unexplained depth limit of 3, vague annotations2 variable, misspelled CONVERTABLE naming, and subtle bidirectional compatibility logic reduce clarity. Code length: Reasonably concise, although annotations2 is redundant and some annotation lookup logic is repeated. Action granularity: Statements generally perform one action per line; compound boolean expressions remain manageable. Reading flow: Consistent formatting and cohesive methods support natural reading, though awkward line breaks in chained calls and fields placed between method groups slightly disrupt flow.
Run 2
Code Structure: Small, focused methods separate signature construction, type compatibility, and annotation lookup, although field declarations interrupt the method grouping. Nesting: Mostly shallow; recursive annotation lookup has manageable loop-and-conditional nesting. Clarity of intent: Descriptive method names and explicit conversion mappings convey purpose well, but the unexplained depth limit of 3, temporary name annotations2, and misspelling CONVERTABLE reduce clarity. Code length: Generally concise, with minor redundancy in the annotations2 alias and an unnecessary else after a return. Action granularity: Statements generally perform one action per line; compound boolean expressions remain readable. Reading flow: Delegation and early returns create a natural flow, though awkward line breaks in chained calls and inconsistent formatting slightly disrupt scanning.
Run 3
Code Structure: Well-organized into small, focused methods for signature creation, type compatibility, and annotation lookup, though placing fields after factory methods slightly interrupts organization. Nesting: Generally shallow; recursive annotation lookup introduces only modest loop-and-condition nesting. Clarity of intent: Descriptive method names and straightforward logic communicate purpose well, but the unexplained depth limit of 3, vague annotations2 variable, and misspelled CONVERTABLE_TYPES_MAP reduce clarity. Code length: Mostly concise, with minor redundancy in the annotations2 alias and the explicit else after a return. Action granularity: Statements generally perform one action per line; compound boolean expressions remain manageable. Reading flow: Consistent formatting and helper extraction support natural reading, although awkward line breaks in chained calls and the subtle bidirectional compatibility logic require extra attention.