Sample
int-694ace123a6d-I03
Replace method, parameter, and local names with length-matched, meaningful but unrelated names
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.791 | 0–1; higher is more readable |
| Dorn | 0.82 | 0–1; higher is more readable |
| Mi | 0.423 | 0–1; higher is more readable |
| LLOC | 53 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.566 | 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.925 | −7.388 |
Intercept 8.87 + feature contributions = -61.999 (log-odds).
Score = sigmoid(-61.999) = 0.
| Score | 0.791 |
|---|
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.82 | +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.957 | −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.048 | +0.477 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 1.514 (log-odds).
Score = sigmoid(1.514) = 0.82.
| Score | 0.423 |
|---|
| Score | 53 |
|---|
Run 1
The code has some positive structural elements like private fields, a nested descriptor class, and short methods. However, readability is severely undermined by misleading naming: methods like 'validateSession', 'validateBalance', 'refreshRequest', and 'refreshAccount' do not reflect their actual operations (registering endpoints, resolving factories, etc.). This creates confusion about intent. Parameters are also poorly named (e.g., 'pendingAddress', 'finalScore', 'nextMode'), which obscures logic. The class mixes concerns and uses inconsistent terminology, making the reading flow disjointed. Although nesting is shallow and line-level granularity is acceptable, the ambiguous naming and unclear purpose dominate the evaluation. Overall, the code is readable only at a syntactic level but fails at semantic clarity.
Run 2
The code has inconsistent and misleading method names (like validateSession, refreshAddress, refreshAccount) that do not reflect their actual actions, making intent unclear. The class mixes registration, validation, and factory resolution logic without clear boundaries. Nesting is moderate, but the refreshAddress and refreshAccount methods contain multiple branches and actions. Several methods perform multiple tasks, and the overall reading flow feels disorganized due to misplaced comments and unrelated naming. Structure is not tangled but lacks cohesion; naming and Javadoc mismatches further reduce clarity.
Run 3
The code is severely obfuscated: method names (validateSession, refreshAddress, etc.) and parameter names (pendingAccount, nextMode, finalScore) are semantically meaningless, completely hiding the intent. Javadoc comments tell a different story than the actual code, adding confusion. Fields are misnamed, and setter/getter pairs perform no validation despite their names. Structure is repetitive and unnecessarily long. While nesting depth is acceptable and action granularity is mostly one-per-line, reading flow is completely disrupted by the deceptive naming. The rename is likely intentional deobfuscation, but from a readability standpoint, this code is nearly impossible to understand without external documentation.
Run 1
Code Structure: Fields, configuration methods, registration logic, factory resolution, and the descriptor class are logically grouped. Nesting: Shallow loops and conditional branches keep complexity manageable. Clarity of intent: Severely weakened by misleading names such as validateSession, refreshAccount, finalScore, and pendingRequest, which do not describe JMS operations. Documentation helps, but references to nonexistent setter and registration names create contradictions; renamed lifecycle methods also obscure interface contracts. Code length: Reasonable for the responsibilities, though accessor documentation and boilerplate add scanning overhead. Action granularity: Generally one action per statement, with sensible wrapping of longer calls. Reading flow: Consistent formatting and straightforward control flow support reading, but readers must repeatedly translate arbitrary identifiers into their actual roles. Overall, sound structural readability is substantially undermined by naming and documentation inconsistencies.
Run 2
Code Structure: Fields, configuration methods, registration logic, and the descriptor class are logically organized. Nesting: Shallow loops and conditional branches keep control flow manageable. Clarity of intent: Severely weakened by misleading method names such as validateSession and refreshAccount, and unrelated variable names such as finalScore and pendingAccount. Documentation partially explains behavior, but references nonexistent method names and renamed lifecycle overrides create confusion. Code length: Reasonable for its responsibilities, though extensive documentation and boilerplate increase reading time. Action granularity: Statements generally perform one action per line, with readable wrapping for longer calls. Reading flow: Formatting and method grouping are consistent, and factory resolution follows a clear priority order; however, readers must repeatedly reconcile names with actual behavior. Overall, the structural readability is good, but inaccurate naming substantially undermines comprehension.
Run 3
Code Structure: Fields, configuration methods, registration logic, and the descriptor class are logically grouped. Nesting: Shallow loops and conditionals keep control flow manageable. Clarity of intent: Severely weakened by misleading names such as validateSession, refreshAccount, finalScore, and pendingAddress, which do not describe their JMS responsibilities. Documentation helps, but references to absent method names and renamed lifecycle methods marked @Override create confusion. Code length: Implementation is reasonably concise, though extensive documentation and repetitive accessors increase scanning effort. Action granularity: Most statements perform one action, with sensible multiline formatting for longer calls. Reading flow: Configuration leads naturally into initialization, factory resolution, and registration, but arbitrary naming forces readers to repeatedly inspect types and method bodies to understand behavior.