Sample
Schnappinger/junit4/org.junit.runner.FilterFactories
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 54.5Δ 18.0 |
| Scalabrino | 0.647 | 0–1; higher is more readable | 28.4Δ 8.0 |
| Dorn | 0.381 | 0–1; higher is more readable | 53.8Δ 17.3 |
| Mi | 0.565 | 0–1; higher is more readable | 47.9Δ 11.4 |
| LLOC | 22 | Logical lines; fewer is more readable | 57.1Δ 20.6 |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs | 66.8Δ 30.4 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 73.8Δ 37.3 |
| BTTF | 0.672 | 0–1; higher is more readable | 72.9Δ 36.5 |
| Human | 3.3 | 1–4; original rating | 36.5 |
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. | 1764 | −58.212 |
| Source linesThe number of non-empty source lines. | 83 | +33.2 |
| 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.489 | −6.734 |
Intercept 8.87 + feature contributions = -22.876 (log-odds).
Score = sigmoid(-22.876) = 0.
| Score | 0.647 |
|---|
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. | 84 | −1.938 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 59 | +1.304 |
| 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. | 115.929 | −1.245 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 115.988 | +1.067 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 60 | −0.956 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 82.701 | +0.746 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.049 | +0.465 |
Intercept 0.07 + feature contributions = -0.487 (log-odds).
Score = sigmoid(-0.487) = 0.381.
| Score | 0.565 |
|---|
| Score | 22 |
|---|
Run 1
The code is highly readable due to its logical class structure, minimal nesting, and clear method separation. Each public method has a distinct purpose: parsing a filter spec, creating from a class name, and creating from a Class object. The private/static helpers follow the single-responsibility principle. Parentheses are minimal (max two levels), and action granularity is well-balanced: declarations, assignments, and return statements are separated sensibly. Reading flow follows a natural top-down progression from high-level parsing to low-level factory instantiation. Javadocs provide clear intent, including exception documentation. Minor deductions: the 'tuple' variable naming in the first method is somewhat vague, and the empty catch blocks rely on a custom exception for context, which slightly reduces immediate clarity. Overall, the code is concise, well-structured, and easy to follow.
Run 2
The code is well-structured with clear separation of concerns into small, focused methods. Javadocs provide useful context for public methods. Nesting is minimal, with only a few if-else and try-catch blocks kept shallow. The methods are concise and each performs a single logical action. Variable names like filterSpec, tuple, and filterFactoryFqcn are descriptive. The splitting logic, while slightly verbose, is readable and the intent is clear. Minor deductions: the tuple variable name is slightly ambiguous, and the empty string default for filter arguments could be explained. Overall the code is easy to follow and maintainable.
Run 3
The code is well-structured with clear separation of concerns and logical method decomposition. Each method has a single responsibility, and public APIs are properly documented. Nesting is minimal, with only one if-else block and basic try-catch patterns. Intent is generally clear from method names and documentation, though the tuple-splitting logic could be slightly clearer. Code length is appropriate — no unnecessary verbosity. Action granularity is good, with one logical operation per line in most cases. Reading flow is natural, following a top-down progression from specification parsing to factory creation. Minor deductions: the unused 'description' parameter in createFilterFromFilterSpec, and the tuple handling could use a small helper or comment to clarify the '=' splitting convention.
Run 1
Code Structure: Small, focused methods logically separate specification parsing, filter creation, and factory instantiation. Nesting: Shallow conditionals and try/catch blocks keep complexity low. Clarity of intent: Descriptive method names and Javadoc explain the purpose, although the unused description parameter, generic tuple name, and class comment referring to factories rather than filters introduce minor ambiguity. Code length: Concise overall, with modest duplication between overloads and repetitive documentation. Action granularity: Statements generally perform one action each; chained reflection calls remain understandable. Reading flow: Methods progress naturally from public entry points to internal helpers, though inconsistent exception qualification slightly disrupts visual consistency.
Run 2
Code Structure: Well-organized utility methods separate specification parsing, filter creation, class loading, and instantiation. Nesting: Shallow if/else and try/catch blocks keep complexity low. Clarity of intent: Descriptive method names, types, and Javadoc communicate purpose, although the unused description parameter, generic tuple name, and class comment claiming methods create FilterFactory objects introduce ambiguity. Code length: Short methods are appropriately concise, with minor duplication between overloads and repetitive documentation. Action granularity: Statements generally perform one action per line; chained reflection calls remain manageable. Reading flow: Public entry points naturally lead to internal helpers, making execution easy to follow. Inconsistent qualification of FilterNotCreatedException slightly disrupts consistency.
Run 3
Code Structure: Well-organized utility methods separate specification parsing, filter creation, class loading, and instantiation. Nesting: Shallow conditionals and try/catch blocks make control flow easy to follow. Clarity of intent: Descriptive method names and Javadoc explain most operations, but the unused description parameter, generic tuple name, and class comment describing factory rather than filter creation cause minor ambiguity. Code length: Short methods remain concise, although overloads duplicate small amounts of logic and documentation is repetitive. Action granularity: Statements generally perform one clear action; chained reflection calls are compact and understandable. Reading flow: Public entry points lead naturally into internal helpers, with consistent formatting and spacing. Mixed qualified and imported exception names slightly weaken consistency.