Sample
int-d501db420bc3-I10
Remove about 40% of line-break groups while retaining structure
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.441 | 0–1; higher is more readable |
| Dorn | 0.035 | 0–1; higher is more readable |
| Mi | 0 | 0–1; higher is more readable |
| LLOC | 33 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.342 | 0–1; higher is more readable |
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. | 3736.929 | −123.319 |
| Source linesThe number of non-empty source lines. | 107 | +42.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.905 | −7.358 |
Intercept 8.87 + feature contributions = -79.006 (log-odds).
Score = sigmoid(-79.006) = 0.
| Score | 0.441 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 251.972 | −7.007 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 251.981 | +3.261 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 107 | −2.752 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 57 | +1.234 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 106.85 | +1.084 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.056 | +0.395 |
Intercept 0.07 + feature contributions = -3.317 (log-odds).
Score = sigmoid(-3.317) = 0.035.
| Score | 0 |
|---|
| Score | 33 |
|---|
Run 1
The code is highly unreadable due to severe formatting issues. Multiple statements are crammed onto single lines, including imports, method signatures, and entire conditional blocks. This violates action granularity and reading flow. Deeply nested conditionals with complex boolean logic, like the bridge method comparison chain, further obscure intent. While the class structure and method names suggest a logical organization, the visual clutter destroys readability. The long, convoluted condition and lack of vertical spacing make it hard to follow execution paths. Javadoc comments are present but are mangled into the code lines. Overall, the code requires significant reformatting to be understandable.
Run 2
The code has serious readability issues. The package declaration and imports are crammed together on single lines, and Javadoc comments are interleaved with method signatures rather than placed above them. This disrupts the natural reading flow and makes the structure difficult to scan. The selectMethods method contains a deeply nested lambda with a complex multi-line boolean condition that is hard to parse. Some lines pack multiple statements (e.g., the Proxy.isProxyClass check), and the selectInvocableMethod method mixes loops, try-catch blocks, and a return statement in a disorganized way. While some parts have reasonable naming and logic is technically sound, the formatting and lack of consistent line breaks make the code unnecessarily difficult to read. Action granularity is inconsistent, and the overall layout feels tangled rather than logically organized.
Run 3
This code is extremely unreadable due to severe formatting issues. The package and imports are collapsed onto single lines, making them difficult to scan. Javadoc comments are concatenated with method signatures, eliminating visual separation. Multiple statements are placed on the same line throughout, especially in methods like selectMethods and selectInvocableMethod, violating the 'one action per line' principle. The deeply nested lambda inside ReflectionUtils.doWithMethods combines multiple boolean checks and a complex if-statement in a single expression, severely hurting comprehension. The vertical structure is almost nonexistent, with method boundaries obscured. While the underlying logic might be reasonable, the presentation is chaotic and forces the reader to mentally parse dense blocks of code. This appears to be the result of aggressive minification rather than purposeful code organization, making it nearly unreadable in its current form.
Run 1
Code Structure: Cohesive utility class with clearly separated method-selection responsibilities and a small callback interface. Nesting: Moderate depth in the loop/lambda/conditional chain and nested exception handling adds complexity. Clarity of intent: Descriptive names and thorough Javadoc explain the purpose, although bridge-method checks require specialized knowledge. Code length: Implementation is reasonably concise; documentation is lengthy but useful, and the compound bridge condition is cumbersome. Action granularity: Several imports, declarations, assignments, control statements, and returns share lines, substantially reducing scanability. Reading flow: Logical execution order is undermined by inconsistent formatting, inline method bodies, and comments attached to closing braces. Consistent line breaks and indentation would materially improve readability without changing the design.
Run 2
Code Structure: A focused utility class with distinct methods and a callback interface provides logical organization. Nesting: Moderate nesting in loops, lambdas, conditionals, and try/catch blocks adds complexity without becoming excessive. Clarity of intent: Descriptive names and thorough Javadoc explain the purpose, though proxy handling and the compound bridge-method condition require careful reading. Code length: Implementation is reasonably concise; extensive documentation adds useful context rather than unnecessary logic. Action granularity: Several lines combine imports, declarations, conditionals, and multiple statements, obscuring individual actions. Reading flow: Inconsistent formatting, compressed method bodies, and comments attached to closing braces disrupt otherwise coherent control flow. Overall, clear design and documentation are undermined substantially by presentation.
Run 3
Code Structure: Cohesive utility class with logically separated selection methods and a callback interface, but compressed formatting obscures boundaries. Nesting: Moderate depth in the loop/lambda/conditional sequence and nested exception handling increases cognitive load. Clarity of intent: Descriptive method names, meaningful variables, and thorough Javadocs explain the purpose; the bridge-method condition is comparatively difficult to interpret. Code length: Implementation is reasonably concise for its functionality, although documentation occupies substantial space and the compound condition is lengthy. Action granularity: Several lines combine imports, declarations, branches, and multiple statements, undermining scanability. Reading flow: The conceptual progression is sensible, but inconsistent line breaks, inline braces, and comments attached to closing braces repeatedly interrupt natural reading.