Sample
int-2fe37cc259f8-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.317 | 0–1; higher is more readable |
| Dorn | 0.124 | 0–1; higher is more readable |
| Mi | 0.082 | 0–1; higher is more readable |
| LLOC | 54 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.218 | 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. | 8064.924 | −266.142 |
| Source linesThe number of non-empty source lines. | 161 | +64.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.1 | −7.649 |
Intercept 8.87 + feature contributions = -200.522 (log-odds).
Score = sigmoid(-200.522) = 0.
| Score | 0.317 |
|---|
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. | 162 | −4.7 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 122 | +3.483 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 122 | −2.379 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 160.864 | +1.839 |
| 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. | 123.951 | −1.585 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 123.981 | +1.196 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.084 | +0.123 |
Intercept 0.07 + feature contributions = -1.952 (log-odds).
Score = sigmoid(-1.952) = 0.124.
| Score | 0.082 |
|---|
| Score | 54 |
|---|
Run 1
The code is moderately readable but has several issues. The structure is mostly logical with clear method separation, but the main method `findTestBeanFactoryMethod` is overly long and complex. Nesting is generally acceptable except in the fully-qualified method name processing loop where conditionals stack up. Naming and intent are clear for the most part. However, there is a dead code block with an obfuscated-looking variable (`lI0O_abe93111`) that serves no purpose and severely hurts readability. Action granularity is mostly one action per line. Reading flow suffers in the long `Assert.state` calls with multi-line lambdas and string formatting. The code handles multiple cases (explicit method name, fully-qualified names, hierarchy search) but tries to do too much in one method. The Javadoc is helpful, but the implementation could benefit from extracting smaller helper methods.
Run 2
The code is generally readable with clear structure and logical organization. It uses appropriate naming conventions, has good Javadoc documentation, and follows a natural flow. The main method `createHandler` is well-organized with clear intent. However, there are some issues: the `findTestBeanFactoryMethod` method is quite long and complex, with multiple responsibilities (parsing fully-qualified names, filtering methods, validating results). The deeply nested conditional logic and multiple Assert statements reduce readability slightly. The suspicious dead-code block `{int lI0O_abe93111=...}` is obfuscated and confusing, suggesting possible automated code manipulation. The method filtering lambda is clear but dense. Overall, this is solid Spring framework code that maintains good practices but could benefit from extracting some logic into smaller helper methods.
Run 3
The code is generally well-structured with clear method separation and good javadoc documentation. The main createHandler method has moderate nesting but reads logically. However, the findTestBeanFactoryMethod method is quite long with multiple nested loops and assertions, making it harder to follow. The fully-qualified method name parsing logic adds complexity. A suspicious line with obfuscated variable 'lI0O_abe93111' appears to be inserted test/debug code that breaks reading flow. While naming is mostly clear, the method overloading creates some ambiguity. Overall, readable but could benefit from extracting the fully-qualified name parsing logic into separate methods.
Run 1
Code Structure: Mostly well organized into handler creation and factory-method discovery, though qualified-name parsing makes one method relatively busy. Nesting: Generally shallow, except for an injected, densely nested block in findMethods. Clarity of intent: Descriptive names, documentation, and useful error messages explain the reflection logic; the opaque variable and meaningless bitwise operations obscure intent locally. Code length: Mostly justified by validation and discovery requirements, but the dead-code block is unnecessary. Action granularity: Most statements perform one action per line; the injected block compresses declarations, conditions, and mutations onto a single line. Reading flow: Logical progression and consistent formatting make most of the class easy to follow, but the unformatted block abruptly disrupts that flow, and multiline predicates require some extra attention.
Run 2
Code Structure: Responsibilities are logically separated into handler creation, factory-method lookup, and recursive search, though the main lookup method is fairly long. Nesting: Most control flow is shallow; fully qualified name handling adds moderate nesting, and the injected block adds needless nested conditionals. Clarity of intent: Descriptive names, documentation, and diagnostic messages explain the intended behavior well, but the opaque variable and hexadecimal arithmetic in findMethods obscure intent and perform no useful action. Code length: Mostly justified by validation and search requirements, with some verbose assertions and an entirely unnecessary block. Action granularity: Most statements occupy separate lines, but the injected block compresses declarations, arithmetic, and branching onto one line. Reading flow: The normal code follows a natural validation-search-result progression with consistent formatting; the unindented obfuscated block sharply interrupts that flow.
Run 3
Code Structure: Responsibilities are logically separated into handler creation, factory-method lookup, and recursive searching, but the injected no-op block disrupts otherwise coherent organization. Nesting: Most logic uses moderate nesting; fully qualified name handling and the injected nested conditionals add complexity. Clarity of intent: Descriptive names, documentation, and explanatory comments clearly convey the main purpose, while the cryptic variable and meaningless arithmetic in findMethods obscure intent. Code length: Most code is justified by validation and lookup requirements, though documentation is extensive and the injected block is unnecessary. Action granularity: Statements generally perform one action per line, except the injected block, which compresses declarations, arithmetic, and nested branches onto one line. Reading flow: The main execution sequence is natural and consistently formatted, but long assertion expressions require careful reading, and the unindented injected block abruptly interrupts the flow.