Sample
int-0e3ee326d341-I04
Replace method, parameter, and local names with deterministic ProGuard-style short identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 1 | 0–1; higher is more readable |
| Scalabrino | 0.945 | 0–1; higher is more readable |
| Dorn | 0.339 | 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 | 2.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.297 | 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. | 1875.317 | −61.885 |
| 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.362 | −6.544 |
Intercept 8.87 + feature contributions = 7.641 (log-odds).
Score = sigmoid(7.641) = 1.
| Score | 0.945 |
|---|
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.982 | −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.96 | +1.938 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 148.982 | +1.599 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.023 | +0.716 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = -0.669 (log-odds).
Score = sigmoid(-0.669) = 0.339.
| Score | 0.041 |
|---|
| Score | 23 |
|---|
Run 1
The code is severely obfuscated. Method names like 'a', 'b', 'c', and parameters like 'a', 'b', 'c' destroy clarity of intent despite the Javadoc comments. All semantic meaning is removed, making the interface impossible to read and understand without decoding each comment. While the structure and nesting are fine, the lack of meaningful identifiers makes the code unreadable and unmaintainable. The score reflects the utterly poor readability due to the naming choices.
Run 2
The code is severely obfuscated. All method names, parameter names, and local variables have been replaced with single letters (a, b, c, d, etc.), completely erasing any semantic meaning. While the Javadoc comments still describe the intended functionality, the code itself is unreadable and impossible to maintain without cross-referencing the documentation for every single method and parameter. This destroys clarity of intent, reading flow, and action granularity. The structure is technically present as an interface, but method signatures are meaningless. The code length is not the primary issue, but the naming is. This appears to be deliberately mangled code, and it fails nearly all readability criteria despite the preserved comments.
Run 3
This code is a heavily obfuscated version of a Java interface. Methods, parameters, and variables are renamed to meaningless single letters (a, b, c, d, etc.), which destroys readability despite the presence of Javadoc comments. The structure is logical, but the intent is ambiguous because names do not convey purpose. The code length is normal for an interface, and nesting is minimal, but the reading flow is severely disrupted by mismatched names. Action granularity is fine (one action per line), but the lack of semantic naming violates core readability principles. Even with documentation, readers must constantly refer back to comments to understand what each method does. This obfuscation undermines maintainability and clarity, making the code nearly unreadable in practice.
Run 1
Code Structure: The interface is logically organized, separating storage operations from update-listener callbacks. Nesting: Minimal nesting makes the declarations easy to scan. Clarity of intent: Single-letter method and parameter names severely obscure purpose, particularly the undocumented a() and b(). Comments explain most operations, but @param names do not match actual parameters, and the snapshot() link references a nonexistent method. Code length: Declarations are concise; documentation adds useful context, though some lines are overly long. Action granularity: Each declaration occupies its own line, with no bundled actions. Reading flow: Consistent spacing and related operation groupings support navigation, but understanding requires repeatedly consulting comments because identifiers convey almost no meaning.
Run 2
Code Structure: The interface logically groups storage operations and places notification callbacks in a separate nested interface. Nesting: Minimal nesting makes the declarations easy to scan. Clarity of intent: Single-letter method and parameter names severely obscure purpose; documentation helps, but its parameter names do not match the signatures, and its snapshot link references a nonexistent method. The undocumented a() and b() are especially ambiguous. Code length: Declarations are concise, though extensive comments and some long lines increase reading effort. Action granularity: Each declaration represents a single operation, with no compounded statements. Reading flow: Consistent spacing and documentation provide a predictable layout, but readers must repeatedly consult comments to interpret methods rather than understand them directly from their names.
Run 3
Code Structure: The interface is logically organized, with storage operations followed by a grouped update-listener interface. Nesting: Minimal nesting makes the declarations easy to scan. Clarity of intent: Descriptive types and extensive documentation explain most operations, but single-letter method and parameter names severely obscure the API; undocumented methods a() and b() have no evident purpose. Javadoc parameter names do not match actual parameters, and the snapshot() reference does not match the declared method c(). Code length: Declarations are concise, though lengthy comments and some long lines increase reading effort. Action granularity: Each declaration represents one operation, with no compounded statements. Reading flow: Consistent formatting and method separation help, but readers must repeatedly consult comments to interpret signatures, disrupting otherwise natural flow.