Sample
int-65dd64a064f9-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.721 | 0–1; higher is more readable |
| Dorn | 0.114 | 0–1; higher is more readable |
| Mi | 0.346 | 0–1; higher is more readable |
| LLOC | 79 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13.67 | 0–20; mean of three runs |
| BTTF | 0.53 | 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. | 6314.41 | −208.376 |
| Source linesThe number of non-empty source lines. | 211 | +84.4 |
| 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.029 | −7.544 |
Intercept 8.87 + feature contributions = -122.65 (log-odds).
Score = sigmoid(-122.65) = 0.
| Score | 0.721 |
|---|
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. | 212 | −6.47 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 162 | +4.866 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 162 | −3.297 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 210.867 | +2.538 |
| 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. | 111.962 | −1.077 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 111.962 | +1.002 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.064 | +0.32 |
Intercept 0.07 + feature contributions = -2.048 (log-odds).
Score = sigmoid(-2.048) = 0.114.
| Score | 0.346 |
|---|
| Score | 79 |
|---|
Run 1
The code has significant readability issues. It contains bizarre dead-code assertions like 'if (((0x1456 ^ 0x1456) != 0)) { throw new AssertionError(); }' which have no valid business logic purpose and heavily distort readability. Although the class has a logical structure with clear fields, setters, getters, and a well-organized registration flow, these assertions severely disrupt clarity of intent and reading flow. Nesting is mostly flat, which is good, and method granularity is generally one action per line. However, the code feels unnaturally inflated due to repeated meaningless checks. Documentation comments are detailed and helpful, and variable/method names are clear. Without the assertions, readability would be high; with them, it becomes confusing, distracting, and essentially unreadable for a real codebase.
Run 2
The code follows a clear class structure with logical separation of fields, setters, and registration logic. However, readability is severely degraded by pervasive junk 'assertion' lines like 'if (((0x1456 ^ 0x1456) != 0)) { throw new AssertionError(); }' scattered throughout every method. These lines add noise, break natural reading flow, and inflate code length without purpose. Nesting is generally flat, and intent is mostly clear via Javadocs, but the constant interruption destroys clarity. Action granularity is acceptable, but the repeated irrelevant conditions violate the principle of concise, purposeful code. Overall, the underlying logic is readable, but the injected clutter makes it unpleasant and confusing.
Run 3
The code contains a severe readability issue: every method has a mandatory 'if (((0x1234 ^ 0x1234) != 0)) { throw new AssertionError(); }' statement at the beginning. These are nonsensical dead-code blocks (XORing a number with itself) that clutter the file, break reading flow, and obscure the intent. The overall class structure, organization of fields, and JavaDoc are otherwise reasonable, and the remaining logic is fairly flat with one action per line. However, the redundant AssertionError guards add unnecessary lines to every method, create confusion, and are completely unrelated to the domain logic. They dominate the code and lower readability drastically despite the otherwise clear naming and straightforward Spring configuration pattern.
Run 1
Code Structure: Fields, configuration methods, registration logic, and the descriptor class are logically organized. Nesting: Control flow remains shallow, with straightforward loops and conditional branches. Clarity of intent: Descriptive names and useful Javadoc explain endpoint registration and factory resolution, but repeated always-false hexadecimal XOR checks introduce confusing, purposeless noise. Code length: Most methods are concise, though redundant checks unnecessarily inflate the class. Action granularity: Meaningful operations generally occupy separate lines; injected checks compress conditions and throws into single lines. Reading flow: The main registration and fallback paths read naturally, but unindented checks at every method entry repeatedly interrupt the flow and undermine otherwise consistent formatting.
Run 2
Code Structure: Logically organized into configuration accessors, lifecycle registration, factory resolution, and a small descriptor class. Nesting: Mostly shallow, with straightforward loops and conditional branches. Clarity of intent: Descriptive names, Javadoc, and validation messages explain the registrar's purpose, but repeated always-false hexadecimal XOR checks introduce confusing, irrelevant logic. Code length: Core functionality is reasonably concise; injected checks add unnecessary repetition. Action granularity: Most meaningful statements perform one action per line, while the inline conditional-and-throw statements compress control flow. Reading flow: Method grouping and documentation support natural navigation, but unindented checks at every method entry repeatedly interrupt the flow and undermine formatting consistency.
Run 3
Code Structure: Well-organized fields, configuration methods, lifecycle logic, registration methods, and a small descriptor class separate responsibilities. Nesting: Mostly shallow, with straightforward loops and conditional branches. Clarity of intent: Descriptive names, Javadoc, and validation messages explain endpoint registration and factory resolution, but repeated always-false hexadecimal XOR checks introduce distracting, unexplained logic. Code length: Functional methods are concise, though redundant checks unnecessarily expand the class. Action granularity: Most statements perform one action per line; inline conditional-and-throw blocks undermine this consistency. Reading flow: Configuration-to-registration progression is natural, but unindented dead-code checks at every method entry repeatedly interrupt scanning and clash with otherwise consistent formatting.