Sample
int-fee55d540629-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.743 | 0–1; higher is more readable |
| Dorn | 0.131 | 0–1; higher is more readable |
| Mi | 0.405 | 0–1; higher is more readable |
| LLOC | 58 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.452 | 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. | 4345.174 | −143.391 |
| Source linesThe number of non-empty source lines. | 187 | +74.8 |
| 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.947 | −7.421 |
Intercept 8.87 + feature contributions = -67.142 (log-odds).
Score = sigmoid(-67.142) = 0.
| Score | 0.743 |
|---|
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. | 188 | −5.62 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 138 | +4.036 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 138 | −2.746 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 186.836 | +2.202 |
| 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. | 120.973 | −1.459 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 120.979 | +1.147 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.048 | +0.475 |
Intercept 0.07 + feature contributions = -1.895 (log-odds).
Score = sigmoid(-1.895) = 0.131.
| Score | 0.405 |
|---|
| Score | 58 |
|---|
Run 1
The code generally follows good structure and has readable Javadoc, clear getters/setters, and a straightforward descriptor class. However, it contains a confusing obfuscated code snippet in afterPropertiesSet() (a meaningless while loop with bitwise XOR operations) that completely breaks the reading flow and intent. The nesting is moderate, and method lengths are appropriate. Action granularity is mostly good, though some method calls span multiple lines. The obfuscated block drops the score significantly because it makes the code appear tampered with or unclear in purpose, violating the clarity-of-intent and reading-flow criteria.
Run 2
The code is generally well-structured with clear separation of concerns, good Javadoc documentation, and logical method organization. Fields are grouped at the top, followed by setters/getters, then business logic. Nesting is minimal with only one if-else chain in resolveContainerFactory. However, readability is significantly impacted by the obfuscated no-op loop in afterPropertiesSet() which appears to be injected garbage code. Additionally, the resolveContainerFactory method uses an if-else chain that could be simplified with early returns or a switch-like pattern. The descriptor inner class is clean and purposeful. Most methods follow single-action-per-line principles, though some lines exceed reasonable length. Overall the code demonstrates good Spring framework patterns but suffers from the mysterious obfuscated code block that breaks reading flow and intent clarity.
Run 3
The code is generally well-structured with clear Javadoc and logical methods, but it contains a severe readability flaw: an obfuscated dummy loop in afterPropertiesSet() with meaningless variables and no functional purpose. This disrupts reading flow and violates clarity of intent. Other issues include a moderately complex resolveContainerFactory method with nested if-else chains and a long error message concatenation. Field declarations are clear, getters/setters are concise, and JmsListenerEndpointDescriptor is a nice helper class. The startImmediately flag logic is understandable but adds minor branching. Overall, the standard Spring patterns and documentation would normally score high, but the injected garbage code drops the score significantly.
Run 1
Code Structure: Fields, configuration methods, registration logic, and the descriptor class are logically organized. Nesting: Most methods are shallow, with straightforward loops and conditional branches; the injected do-while block adds unnecessary nesting. Clarity of intent: Descriptive names, Javadoc, assertions, and comments clearly explain endpoint registration and factory resolution, but the opaque variables and hexadecimal operations in afterPropertiesSet obscure intent. Code length: Most implementation methods are concise; documentation and accessors add reasonable length, while the injected block is entirely unnecessary. Action granularity: Almost all statements occupy separate lines, except the injected block, which compresses multiple declarations and operations onto one line. Reading flow: Configuration leads naturally into initialization and registration, with consistent formatting throughout most of the class. The unindented, obfuscated block abruptly disrupts that flow and reduces otherwise strong readability.
Run 2
Code Structure: Well organized into configuration accessors, lifecycle handling, registration, factory resolution, and a small descriptor class. Nesting: Generally shallow, with straightforward loops and conditional branches; the injected block adds unnecessary nesting. Clarity of intent: Descriptive names, assertions, and Javadoc explain most behavior clearly, but the cryptically named variables and pointless do-while loop in afterPropertiesSet obscure its simple purpose. Code length: Most methods are concise; extensive documentation is useful, while the injected block is unnecessary. Action granularity: Most lines perform one action, but the injected block compresses several declarations and operations onto one line. Reading flow: Consistent formatting and logical method ordering make the class easy to follow overall, although the unindented obfuscated block sharply interrupts that flow.
Run 3
Code Structure: Configuration, lifecycle, factory resolution, and registration are logically separated into focused methods. Nesting: Most logic is shallow; the factory fallback chain is easy to follow, but the injected block adds unnecessary nesting. Clarity of intent: Descriptive names, assertions, and Javadoc clearly explain the registrar's purpose, except for the meaningless hexadecimal operations and opaque variable names in afterPropertiesSet. Code length: Generally appropriate for the API, although extensive documentation and boilerplate add length, and the injected block is entirely unnecessary. Action granularity: Nearly all statements perform one action per line; the compressed injected block violates this strongly. Reading flow: Consistent formatting and sensible method ordering support natural reading, but the unindented, single-line do-while block abruptly disrupts it.