Sample
int-8e8b3827c6b9-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.814 | 0–1; higher is more readable |
| Dorn | 0.816 | 0–1; higher is more readable |
| Mi | 0.426 | 0–1; higher is more readable |
| LLOC | 53 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 4.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs |
| BTTF | 0.608 | 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. | 4166.101 | −137.481 |
| Source linesThe number of non-empty source lines. | 185 | +74 |
| 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.924 | −7.386 |
Intercept 8.87 + feature contributions = -61.997 (log-odds).
Score = sigmoid(-61.997) = 0.
| Score | 0.814 |
|---|
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. | 186 | −5.549 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 136 | +3.967 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 184.829 | +2.174 |
| 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. | 109.946 | −0.992 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 109.957 | +0.97 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.05 | +0.454 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 1.491 (log-odds).
Score = sigmoid(1.491) = 0.816.
| Score | 0.426 |
|---|
| Score | 53 |
|---|
Run 1
The code has good structural organization and documentation but suffers from poor readability due to obfuscated method and variable names. Methods like set(), set2(), set3(), set4(), set5(), register2(), and variables like des2, des3, end2, end3, container2, container3 obscure the intent. This makes the code difficult to follow and maintain despite its clear logical flow. The nesting is shallow, and action granularity is mostly reasonable, but the naming convention forces readers to cross-reference the original Spring source code to understand the purpose. The use of @Nullable annotations and comments is helpful, but the placeholder-style suffixes (e.g., '2', '3') indicate either incomplete renaming or obfuscation for evaluation purposes. Code length is moderate for a configuration helper, and reading flow is natural aside from the naming issues. Overall, the code would be readable if proper method names were restored, but as presented it is below average.
Run 2
The code is severely obfuscated through deliberate renaming. Methods like 'set', 'set2', 'set3', 'set4', 'set5', 'register2', 'after' and variables 'des2', 'des3', 'end2', 'end3', 'container2', 'container3' completely destroy clarity of intent, making it impossible to understand the code's purpose without extensive cross-referencing. The original descriptive names (setEndpointRegistry, setMessageHandlerMethodFactory, etc.) appear to have been intentionally stripped away. The variable naming within the private static class is equally egregious. While the code structure is technically flat and one action generally occurs per line, these aspects cannot compensate for the fundamental unreadability caused by meaningless identifiers. The jarring inconsistency between the descriptive Javadoc (which references methods that don't exist or have been renamed) and the actual code further compounds the confusion. This appears to be a deliberately sabotaged or 'obfuscated' version of perfectly readable Spring Framework code.
Run 3
The code is heavily obfuscated with meaningless method and variable names (e.g., set, set2, set3, resolve, end2, fac, des3). This destroys clarity of intent, despite the Javadoc explaining what each method should do. The structure is moderately logical, matching typical Spring registrar patterns, but the naming makes it nonsensical. Nesting and action granularity are acceptable — methods are short and do one thing per line. However, reading flow is severely disrupted because identifiers do not reflect their purpose. For example, 'set' should be 'setEndpointRegistry', 'get' should be 'getEndpointRegistry', and 'set5' should be 'setBeanFactory'. Overall, the code is technically well-structured but practically unreadable to any developer unfamiliar with the original names. Code length is reasonable and concise, with only a slight unnecessary extension in the resolve method. The primary issue is not complexity but severe loss of semantic meaning.
Run 1
Code Structure: Fields, configuration methods, registration logic, factory resolution, and the descriptor class are logically organized. Nesting: Shallow loops and conditional branches keep complexity manageable. Clarity of intent: Descriptive class and field names and extensive documentation help, but generic numbered methods (set2, set5, register2) and abbreviated variables obscure purpose. Documentation references original method names that no longer exist, and renamed lifecycle methods conflict with the implemented interfaces, further confusing readers. Code length: Reasonably concise implementation, although accessor documentation adds considerable length. Action granularity: Statements generally perform one action per line, with readable formatting for longer calls. Reading flow: Configuration followed by initialization and registration is natural, but inconsistent naming forces readers to repeatedly consult types, comments, and method bodies.
Run 2
Code Structure: Logically separates configuration, registration, factory resolution, and endpoint data into focused methods and a small nested class. Nesting: Shallow loops and conditionals keep control flow manageable. Clarity of intent: Descriptive fields, types, and documentation help, but generic names such as set2, set5, after, des2, and register2 obscure responsibilities. Documentation references original method names that no longer exist, and renamed lifecycle methods conflict with the implemented interfaces, further confusing intent. Code length: Implementation is reasonably concise, although extensive accessor documentation increases reading overhead. Action granularity: Statements generally perform one action per line; wrapped calls remain understandable. Reading flow: Configuration methods precede lifecycle and registration logic naturally, but numbered names and inconsistent parameter naming interrupt comprehension and force readers to inspect method bodies.
Run 3
Code Structure: Fields, configuration methods, registration logic, factory resolution, and the descriptor class are logically grouped. Nesting: Shallow loops and conditional branches keep control flow manageable. Clarity of intent: Descriptive field names and detailed documentation help, but generic numbered methods such as set2, set5, and register2, plus abbreviated variables, obscure purpose. Documentation references methods that no longer exist, and renamed lifecycle methods conflict with the implemented interfaces, further confusing readers. Code length: Implementation methods are concise, although repetitive accessors and extensive documentation increase overall length. Action granularity: Statements generally perform one action per line; wrapped calls remain easy to follow. Reading flow: Consistent formatting and sensible method ordering support navigation, but ambiguous names and stale references force readers to infer behavior from method bodies.