Sample
int-80014ceb2bcd-I04
Replace method, parameter, and local names with deterministic ProGuard-style short identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.735 | 0–1; higher is more readable |
| Dorn | 0.778 | 0–1; higher is more readable |
| Mi | 0.565 | 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 | 10 | 0–20; mean of three runs |
| BTTF | 0.415 | 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. | 3758.09 | −124.017 |
| Source linesThe number of non-empty source lines. | 143 | +57.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.929 | −7.394 |
Intercept 8.87 + feature contributions = -65.341 (log-odds).
Score = sigmoid(-65.341) = 0.
| Score | 0.735 |
|---|
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. | 143 | −4.027 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 93 | +2.48 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 142.849 | +1.587 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 90.694 | +0.659 |
| 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.064 | +0.32 |
| 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. | 91.993 | −0.231 |
Intercept 0.07 + feature contributions = 1.255 (log-odds).
Score = sigmoid(1.255) = 0.778.
| Score | 0.565 |
|---|
| Score | 33 |
|---|
Run 1
The code structure is severely obfuscated by generic, meaningless variable names (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t). Method names like 'a' and 'b' completely obscure intent. While the logical flow is not overly nested, the 'a' method contains dense conditional logic on a single line which requires significant mental parsing. The single-letter naming forces the reader to constantly map variables to their conceptual roles, destroying natural reading flow. Action granularity is acceptable, with one primary action per line, but clarity of intent is virtually nil. Although the original Javadocs help somewhat, they discuss intent but don't fix the identifiers. The code is concise but at the cost of total unreadability.
Run 2
The code is extremely unreadable due to single-character variable names (a, b, c, d, etc.) that are meaningless, making the logic nearly impossible to follow without the original names. The parameter names in methods, loops, and lambdas obscure intent, despite the presence of descriptive Javadoc. The structure is otherwise logical but the naming destroys clarity. Nesting is moderate, reading flow is disrupted by opaque identifiers, and the lambda body has multiple actions. Code length is reasonable but misleading because the cryptic names require constant mental mapping. The public API is unusable without reconstructed context from the documentation. Renaming variables to meaningful terms (targetType, metadataLookup, result, etc.) would dramatically improve readability. Action granularity is okay in most places but suffers from the same naming issues. Overall, it reads like obfuscated source code rather than maintainable Spring framework code.
Run 3
The code has severely obfuscated variable and method names (a, b, c, d, etc.) making it very hard to understand intent. While it has some positive aspects like flat nesting, reasonable method lengths, and single actions per line, the single-letter naming destroys clarity. The structure is logical but impossible to follow without significant mental mapping. Method names like 'a' and 'b' provide zero semantic meaning. The reading flow is disrupted by having to constantly backtrack to understand what each variable represents. Even with good Javadoc, the implementation is nearly unreadable as written. This appears to be intentionally obfuscated code that would need complete renaming to be maintainable.
Run 1
Code Structure: Distinct methods and a callback interface provide logical organization. Nesting: Moderate nesting in the method traversal lambda and nested exception handling adds complexity but remains manageable. Clarity of intent: Single-letter method and variable names severely obscure purpose; Javadoc helps, but its parameter names do not match the signatures. Calls to inspect also conflict with the callback's declared method a, disrupting comprehension. Code length: Implementation is reasonably concise, with extensive but useful documentation. Action granularity: Most lines perform one action, although the chained filter conversion and compound bridge-method condition require additional parsing. Reading flow: Consistent formatting, early returns, and ordered traversal support natural reading, but opaque identifiers and declaration inconsistencies repeatedly force readers to reconstruct meaning.
Run 2
Code Structure: Well-organized utility class with separate selection and invocation methods and a dedicated callback interface. Nesting: Moderate nesting in the method-processing lambda and interface search adds complexity but remains manageable. Clarity of intent: Single-letter method and variable names severely obscure roles; Javadoc helps, but parameter names do not match signatures, and calls to inspect conflict with the callback method named a. Code length: Implementation is reasonably concise for reflection and proxy handling, though extensive documentation increases reading overhead. Action granularity: Most lines perform one action; the compound bridge-method condition and chained filter expression require extra parsing. Reading flow: Consistent formatting and logical sequencing support navigation, but opaque identifiers force repeated cross-referencing, interrupting otherwise natural flow.
Run 3
Code Structure: Distinct utility methods and a callback interface provide logical organization. Nesting: Moderate nesting in the method-selection lambda and interface-search exception handling increases effort but remains manageable. Clarity of intent: Single-letter method and variable names severely obscure purpose; Javadocs help, but parameter names do not match the signatures. Calls to inspect also conflict with the callback's declared method a, making the intended API confusing. Code length: Implementation is reasonably concise, though extensive documentation outweighs the code. Action granularity: Most lines perform one action; the filter overload combines casting, a lambda, delegation, and result extraction into one expression. Reading flow: Consistent formatting and sensible sequencing support navigation, but opaque identifiers and a compound bridge-method condition repeatedly interrupt comprehension.