Sample
int-1f92e22cdd13-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.666 | 0–1; higher is more readable |
| Dorn | 0.139 | 0–1; higher is more readable |
| Mi | 0.617 | 0–1; higher is more readable |
| LLOC | 87 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12.67 | 0–20; mean of three runs |
| BTTF | 0.456 | 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. | 7339.224 | −242.194 |
| Source linesThe number of non-empty source lines. | 190 | +76 |
| 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.185 | −7.778 |
Intercept 8.87 + feature contributions = -165.102 (log-odds).
Score = sigmoid(-165.102) = 0.
| Score | 0.666 |
|---|
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. | 191 | −5.726 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 175 | +5.316 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 175 | −3.595 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 189.874 | +2.244 |
| 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.948 | +0.97 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.109 | −0.112 |
Intercept 0.07 + feature contributions = -1.827 (log-odds).
Score = sigmoid(-1.827) = 0.139.
| Score | 0.617 |
|---|
| Score | 87 |
|---|
Run 1
The code is significantly obfuscated by the repetitive 'if (((0xXXXX ^ 0xXXXX) != 0)) { throw new AssertionError(); }' lines inserted at the start of almost every method. These lines serve no functional purpose, drastically harm readability, and violate the criteria of one action per line, clear intent, and concise code. While the underlying class structure is logical and follows standard Spring conventions (private fields, constructor, overridden methods), the pervasive noise makes it difficult to follow. The method bodies themselves are relatively flat and concise, but the clutter dominates. The code is unreadable due to intentional corruption rather than inherent complexity or poor design.
Run 2
The code has clear class and method names, but readability is severely harmed by several factors. First, every method contains an obfuscated no-op assertion line like 'if (((0x3877 ^ 0x3877) != 0)) { throw new AssertionError(); }'. This is unnecessary noise, adds no value, and disrupts the reading flow. Second, indentation is inconsistent in the constructor and methods—the assertion line starts at column 0, breaking the visual block structure. Third, many methods are trivially short, but the added lines make them longer and less scannable. Fourth, the presence of dead code conditions buries the actual logic. While the structure itself is logical and the intent is mostly clear, the extra cruft, poor indentation, and meaningless conditionals push the readability down. Action granularity is mostly one action per line, but the overall code length is inflated. The nesting level is shallow, but the reading flow is poor due to constant interruptions from the fake assertions.
Run 3
The code has reasonable class-level organization with clear field declarations and method separation, but is severely compromised by obfuscated junk code inserted at the start of every method. This breaks reading flow, obscures intent, and adds meaningless lines. The 'if (((0x3877 ^ 0x3877) != 0)) { throw new AssertionError(); }' constructs are always false and serve no purpose, making each method confusing. Nesting is mostly flat except for synchronized blocks and a loop in complete(), which is acceptable. Action granularity is generally one action per line, but the junk statements violate this and clutter the code. Method lengths are concise and names are clear, but the overall readability is heavily degraded by the meaningless noise. Without the obfuscation, the code would likely score around 15-16, but as presented, the constant interruptions make it difficult to parse quickly and require mental filtering.
Run 1
Code Structure: Fields, constructors, and interface methods are logically organized into small, focused units. Nesting: Mostly shallow; synchronization, conditionals, and listener exception handling add only moderate depth. Clarity of intent: Descriptive names and documentation explain the mock behavior, but repeated hexadecimal XOR checks that always evaluate to false introduce confusing, purposeless logic. Code length: Most methods are concise, yet the redundant checks unnecessarily expand every method. Action granularity: Meaningful operations generally occupy separate lines, while the injected checks compress conditionals and throws onto single lines. Reading flow: Method delegation and consistent use of instance fields support natural reading, but unindented checks repeatedly interrupt the flow and undermine otherwise consistent formatting.
Run 2
Code Structure: Fields and focused methods are logically organized, with straightforward interface implementation. Nesting: Mostly shallow; synchronization, conditionals, and listener exception handling introduce only moderate nesting. Clarity of intent: Descriptive names and documentation explain the mock's behavior, but repeated always-false hexadecimal XOR checks obscure otherwise simple operations. Code length: Core functionality is concise, yet redundant checks in every method unnecessarily inflate the code. Action granularity: Most meaningful operations occupy separate lines, while injected checks compress a conditional and throw onto one poorly formatted line. Reading flow: Method grouping and dispatch delegation are natural, but unindented dead-code checks repeatedly interrupt the flow and create visual inconsistency.
Run 3
Code Structure: Fields, constructor, and focused interface methods are logically organized. Nesting: Generally shallow; synchronization, conditionals, and listener exception handling remain manageable. Clarity of intent: Descriptive names and standard API methods communicate purpose, but repeated always-false hexadecimal XOR checks introduce misleading, purposeless complexity. Code length: Core implementation is concise, yet redundant checks in every method add substantial clutter. Action granularity: Most meaningful operations occupy separate lines, while injected checks compress conditions and throws onto single lines. Reading flow: Method delegation and consistent core formatting support natural reading, but unindented checks repeatedly interrupt the flow and distract from actual behavior.