Sample
int-7cf91c2a19b7-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.256 | 0–1; higher is more readable |
| Dorn | 0.163 | 0–1; higher is more readable |
| Mi | 0.067 | 0–1; higher is more readable |
| LLOC | 49 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10.67 | 0–20; mean of three runs |
| BTTF | 0.343 | 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. | 7723.315 | −254.869 |
| Source linesThe number of non-empty source lines. | 159 | +63.6 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 5.061 | −7.591 |
Intercept 8.87 + feature contributions = -189.991 (log-odds).
Score = sigmoid(-189.991) = 0.
| Score | 0.256 |
|---|
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. | 160 | −4.629 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 120 | +3.414 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 120 | −2.333 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 158.912 | +1.811 |
| 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. | 112.95 | −1.119 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 112.975 | +1.018 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.083 | +0.133 |
Intercept 0.07 + feature contributions = -1.634 (log-odds).
Score = sigmoid(-1.634) = 0.163.
| Score | 0.067 |
|---|
| Score | 49 |
|---|
Run 1
The code exhibits severe readability issues due to misleading and nonsensical variable/parameter names throughout. Parameters like 'defaultMessage' (an Annotation), 'nextToken', 'batch' (a Field), 'price', 'pendingAddress', 'remoteIndex', 'defaultBalance', and 'defaultMode' obscure the actual purposes, making intent nearly impossible to infer. Method names like 'validateAccount' and 'parseBuffer' do not reflect their true functions (finding factory methods). While the code structure is moderately organized with separate methods, the ambiguous naming creates a tangled, confusing logic flow. Nesting is reasonably flat, but clarity of intent is severely compromised. The code is not excessively long for its logic, but the obfuscated identifiers require constant mental mapping. Action granularity varies, with some lines doing multiple things (especially in loops). Overall, the code is extremely difficult to read and maintain despite having a logical underlying purpose, as every identifier requires deciphering.
Run 2
This code is heavily obfuscated with meaningless variable names (e.g., 'validateAccount' for finding factory methods, 'batch' for a Field, 'defaultMessage' for an Annotation) that obscure intent. The method names do not reflect their actual behavior, making the logic very difficult to follow. Nesting is moderate but the use of streams, nested conditionals, and recursive helper methods adds complexity. Action granularity is inconsistent; some lines bundle multiple operations while others are verbose. Reading flow is severely disrupted by the non-semantic naming and misleading comments that reference the original Spring code's purpose but do not match the obfuscated identifiers. The structure is preserved from a well-organized codebase, but the renaming destroys clarity of intent, making this effectively unreadable for understanding or maintenance.
Run 3
The code is heavily obfuscated despite its structural organization. Variable and method names are misleading or meaningless (e.g., 'validateEvent' for what appears to be a handle creation method, 'defaultMessage' for a TestBean annotation, 'batch' for a Field, 'nextToken' for a Class). The 'validateAccount' method is overloaded in confusing ways, mixing collection and varargs. Deeply nested logic with unclear intent makes the code hard to follow. While the code is formatted consistently and uses helpers, the naming and flow severely undermine readability. The original intent appears to be lost through aggressive renaming, resulting in ambiguous and difficult-to-maintain code.
Run 1
1. Code Structure: Responsibilities are reasonably separated into annotation processing, factory-method lookup, and enclosing-class traversal, but misleading method names obscure this organization. 2. Nesting: Mostly shallow; the fully qualified name loop adds moderate nesting through conditionals and exception handling. 3. Clarity of intent: The main weakness is arbitrary names such as shipment, feature, and pendingRequest, which conceal domain meaning. Comments explain the intended behavior, but Javadoc references and parameter names do not match the actual declarations. 4. Code length: Generally proportionate to the task, although extensive documentation and repetitive reflection checks increase reading effort. 5. Action granularity: Most statements perform one action per line; multiline predicates and exception construction remain manageable. 6. Reading flow: Control flow follows a logical sequence, but inconsistent terminology, stale documentation, and dense expressions repeatedly interrupt comprehension.
Run 2
Code Structure: Methods separate annotation processing, factory lookup, and enclosing-class traversal logically. Nesting: Mostly shallow, though fully qualified name handling combines a loop, conditional, and try/catch. Clarity of intent: The main weakness is misleading names such as validateAccount, shipment, and parseBuffer; these obscure bean-factory semantics. Documentation helps, but references and parameter names do not match the actual declarations. Code length: Reasonably proportionate to the task, although extensive documentation and repetitive assertions add reading overhead. Action granularity: Generally one action per line, with longer compound predicates and formatted assertions requiring extra attention. Reading flow: The processing sequence is coherent, but unrelated identifiers and dense reflection logic repeatedly interrupt comprehension. Overall, sound organization and restrained nesting are undermined by poor semantic naming and inconsistent documentation.
Run 3
Code Structure: Responsibilities are separated into annotation processing, factory-method lookup, and recursive enclosing-class search, providing logical organization. Nesting: Mostly moderate, though the fully qualified name loop combines conditionals and exception handling. Clarity of intent: Severely weakened by misleading names such as validateAccount, shipment, and parseBuffer; documentation also references nonexistent methods and mismatched parameter names. Comments and framework APIs partially clarify the purpose. Code length: Reasonable for the functionality, but verbose documentation and repeated assertion formatting add reading overhead. Action granularity: Generally one action per statement, with some dense predicates, lambdas, and constructor arguments requiring extra parsing. Reading flow: The overall sequence is coherent, but unrelated identifiers force readers to repeatedly infer each variable's role, and stale documentation interrupts understanding.