Sample
int-56a2f9083de6-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.976 | 0–1; higher is more readable |
| Scalabrino | 0.901 | 0–1; higher is more readable |
| Dorn | 0.07 | 0–1; higher is more readable |
| Mi | 0.041 | 0–1; higher is more readable |
| LLOC | 23 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11.33 | 0–20; mean of three runs |
| BTTF | 0.564 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 168 | +67.2 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 1992.999 | −65.769 |
| 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.392 | −6.588 |
Intercept 8.87 + feature contributions = 3.713 (log-odds).
Score = sigmoid(3.713) = 0.976.
| Score | 0.901 |
|---|
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. | 169 | −4.947 |
| 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. | 148.988 | −2.645 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 85 | +2.203 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 167.927 | +1.937 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 148.982 | +1.599 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 85 | −1.53 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.023 | +0.721 |
Intercept 0.07 + feature contributions = -2.591 (log-odds).
Score = sigmoid(-2.591) = 0.07.
| Score | 0.041 |
|---|
| Score | 23 |
|---|
Run 1
This code is severely obfuscated and unreadable. Method names have been reduced to meaningless tokens like 'sta()', 'sto()', 'sna()', 'con()', and 'put2()' through 'put7()', destroying the original descriptive names (start, stop, snapshot, contains, putConnectorConfig, putTaskConfigs, etc.). Parameter names like 'con2', 'pro', 'con5', 'tim', 'uni', 'sta', 'nam', 'lev', 'lis', and 'session2' provide no semantic meaning. While the Javadoc comments remain descriptive, they create a jarring disconnect with the degraded code they document. The interface structure is logically organized, and each method performs a single action, but the cryptic naming completely obscures the intent and makes the code extremely difficult to follow without constantly cross-referencing comments. This represents a worst-case scenario where otherwise well-structured code is rendered nearly unreadable through deliberate name mangling.
Run 2
The code is structurally intact (proper package, imports, interface) but unreadable due to intentional obfuscation of all identifiers. Method names like 'sta', 'sto', 'sna', 'con', 'put2', 'put7' obscure intent completely. Parameter names are cryptic ('con7', 'nam2', 'session2'). This violates clarity of intent, reading flow, and action granularity. While the Javadoc comments are detailed, they do not map meaningfully to the mangled method names, causing cognitive friction. Nesting is flat, but method count and arbitrary numbering create disorganization. Code is concise, but at the cost of meaning. Overall, the structure shows an underlying API, but the deliberate removal of meaningful names makes it effectively unreadable for practical use.
Run 3
The code is severely obfuscated through systematic renaming of all methods and parameters to meaningless abbreviations (sta, sto, sna, con, con2, con3, etc.). This destroys clarity of intent completely, making the interface impossible to understand without external documentation. While the structure retains some logical grouping and nesting is flat, the code length is artificially reduced at the expense of all semantic meaning. Action granularity is technically one action per line, but reading flow is completely disrupted by the nonsensical names. The Javadoc comments still describe original intent, creating a jarring disconnect between documentation and code. This appears to be deliberately de-identified code that would fail any professional code review.
Run 1
Code Structure: Logically organized as a storage interface with a separate nested listener interface. Nesting: Shallow, with no complex control flow. Clarity of intent: Substantially weakened by abbreviated names and numbered methods such as put2, put7, and on6; descriptive Javadocs help, but mismatched @param names and the nonexistent snapshot() reference undermine accuracy. Code length: Reasonable for the API scope, although documentation dominates and some lines are overly long. Action granularity: Each declaration occupies its own line, making individual operations easy to isolate. Reading flow: Consistent spacing and method documentation support scanning, but understanding operations requires repeatedly consulting comments because signatures convey little meaning.
Run 2
Code Structure: The interface logically groups storage operations and separates callbacks into UpdateListener. Nesting: Minimal nesting makes declarations easy to scan. Clarity of intent: Severely weakened by abbreviated names such as sta, sna, and con, and numbered methods such as put2 and on6. Documentation explains most operations, but parameter tags do not match actual names, and the snapshot link references a nonexistent method. Code length: Declarations are concise; extensive documentation is mostly useful but compensates for poor naming. Action granularity: Each declaration occupies its own line, with no combined actions. Reading flow: Consistent spacing and method-level comments support navigation, but opaque identifiers force readers to consult documentation repeatedly. Overall, strong structural readability is undermined by ambiguous naming and inconsistent documentation.
Run 3
Code Structure: The interface is logically organized, with storage operations followed by a nested update-listener interface. Nesting: Minimal nesting and no complex control flow make the layout easy to scan. Clarity of intent: Severely weakened by abbreviated and numbered names such as sta, put6, and on7; readers must rely on documentation to distinguish operations. Javadoc parameter names do not match declarations, and the snapshot link references a missing method, reducing documentation reliability. Code length: Declarations are concise, although extensive comments compensate for unclear naming and include some long lines. Action granularity: Each declaration represents a single operation, with no combined statements. Reading flow: Consistent spacing and documentation support sequential reading, but cryptic identifiers and documentation mismatches repeatedly interrupt comprehension.