Sample
int-351b5b3a9847-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.857 | 0–1; higher is more readable |
| Dorn | 0.813 | 0–1; higher is more readable |
| Mi | 0.429 | 0–1; higher is more readable |
| LLOC | 53 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 4.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.517 | 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. | 4074.825 | −134.469 |
| 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.933 | −7.4 |
Intercept 8.87 + feature contributions = -58.999 (log-odds).
Score = sigmoid(-58.999) = 0.
| Score | 0.857 |
|---|
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.865 | +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.984 | −0.993 |
| 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.052 | +0.437 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 1.473 (log-odds).
Score = sigmoid(1.473) = 0.813.
| Score | 0.429 |
|---|
| Score | 53 |
|---|
Run 1
The code is significantly unreadable due to obfuscated method names (a-k), unclear parameter names, and misleading documentation. The structure resembles tangled code because all methods are renamed without semantic meaning, making intent ambiguous. Nesting is moderate but not problematic; however, action granularity and reading flow are severely impacted by generic names like 'j' and 'k' that conflict with local variables. Clarity of intent is lost—readers cannot infer what each method does without deep analysis. Although the code length is not excessive, the pervasive use of single letters and overloaded methods with identical names but different parameters creates confusion. Overall, this appears deliberately obfuscated and would be extremely difficult to maintain or review.
Run 2
The code structure is severely compromised by meaningless method and parameter names (e.g., a(), b(), c(), j(), k()). This destroys clarity of intent and reading flow, as readers cannot infer purpose from names. Nesting is moderate but the deeply chained if-else in method j() adds complexity. Action granularity is mostly acceptable, but the Javadoc references non-existent method names like setContainerFactoryBeanName, worsening ambiguity. Code length is reasonable, but readability collapses due to cryptic naming and inconsistent documentation. The class has a clear original structure, but the obfuscated identifiers make it practically unreadable.
Run 3
The code has been deliberately obfuscated, making it nearly unreadable. Method and parameter names like 'a', 'b', 'c', and 'j' obscure their purpose, forcing readers to rely on comments or guess intent. The original structure appears logical (registrar pattern), but renaming breaks clarity of intent drastically. Nesting is moderate, but the long conditional block in method 'j' reduces readability. Action granularity is acceptable, but the reading flow is unnatural due to meaningless names. While Javadocs remain, they do not compensate for the loss of self-documenting code. The code performs multiple actions per line in some places, especially the conditional returns and combined calls. Overall, the structure is intact but the naming destroys readability.
Run 1
1. Code Structure: Logically organized into configuration accessors, initialization, factory resolution, registration, and a small descriptor class. 2. Nesting: Shallow loops and conditional branches are easy to follow. 3. Clarity of intent: Descriptive fields and extensive documentation help, but single-letter method and parameter names severely obscure operations; expressions such as j(j) and k(k, null) are especially confusing. Documentation references original method names that no longer match the code. 4. Code length: Implementation is reasonably concise, although accessor documentation adds substantial length. 5. Action granularity: Statements generally perform one action per line, with appropriate wrapping for longer calls. 6. Reading flow: Consistent formatting and logical grouping support navigation, but cryptic names force readers to repeatedly inspect definitions and comments to understand calls.
Run 2
Code Structure: Logically organized into configuration methods, initialization, factory resolution, endpoint registration, and a small descriptor class. Nesting: Shallow loops and conditional branches keep control flow manageable. Clarity of intent: Descriptive fields, types, and documentation help, but single-letter methods and parameters severely obscure purpose; expressions such as j(j) and k(k, null) are particularly confusing. Documentation references also retain method names absent from the code. Code length: Implementation is reasonably concise, though extensive documentation and repetitive accessors increase reading length. Action granularity: Generally one action per statement, with clear separation of validation, object creation, and registration. Reading flow: Method ordering and consistent formatting support navigation, but opaque names force readers to repeatedly infer behavior from implementations and comments.
Run 3
Code Structure: Fields, configuration methods, registration logic, and the descriptor class are logically organized. Nesting: Control flow is shallow, with straightforward loops and conditional branches. Clarity of intent: Descriptive fields and extensive documentation help, but single-letter method and parameter names severely obscure behavior; j(j) and k(k, null) are especially confusing. Documentation references also name methods absent from the code. Code length: Implementation is reasonably concise, though accessor documentation and whitespace add bulk. Action granularity: Statements generally perform one action each, with clear separation of validation, construction, and registration. Reading flow: Configuration followed by initialization and registration is natural, but opaque names force readers to repeatedly inspect implementations to understand calls.