Sample
int-360fec0d275e-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.771 | 0–1; higher is more readable |
| Dorn | 0.15 | 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 | 14.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.513 | 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. | 4385.783 | −144.731 |
| Source linesThe number of non-empty source lines. | 194 | +77.6 |
| 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.903 | −7.354 |
Intercept 8.87 + feature contributions = -65.615 (log-odds).
Score = sigmoid(-65.615) = 0.
| Score | 0.771 |
|---|
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. | 195 | −5.868 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 145 | +4.278 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 145 | −2.906 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 193.894 | +2.3 |
| 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.979 | −1.078 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 111.969 | +1.002 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.049 | +0.465 |
Intercept 0.07 + feature contributions = -1.736 (log-odds).
Score = sigmoid(-1.736) = 0.15.
| Score | 0.405 |
|---|
| Score | 58 |
|---|
Run 1
The code generally exhibits clear structure with logical separation of methods, shallow nesting, and explicit Javadoc comments explaining intent. However, a significant readability issue is apparent: a stray unrelated code block (a loop counting even numbers) is erroneously inserted inside the JmsListenerEndpointDescriptor constructor. This has no connection to the surrounding logic, violates the single-responsibility principle, and disrupts reading flow. Method granularity is appropriate, variable naming is descriptive, and the 'resolveContainerFactory' logic, while branching across multiple conditions, remains flat and understandable. The file is somewhat long but mostly due to extensive documentation. The primary deduction is due to the misplaced and confusing code fragment. Without that block, the code would score higher.
Run 2
The code is generally well-structured with clear separation of concerns, minimal nesting, and good method-level clarity. Javadoc comments explain intent well. However, a major readability issue is the stray code block inside the JmsListenerEndpointDescriptor constructor: it contains an unrelated even-number-counting loop that appears to be accidental or misplaced, severely disrupting reading flow and action granularity. Additionally, the resolveContainerFactory method has a four-branch conditional that, while not deeply nested, is somewhat lengthy and could be extracted for clarity. The registerEndpoint method has moderate branching and nuanced timing logic (startImmediately) that is explained by a single comment, but may still be non-obvious. Overall, the code is professional and maintainable, but the erroneous block and conditional complexity prevent a higher score.
Run 3
The code demonstrates generally clear structure with logical method organization, minimal nesting, and helpful Javadoc comments. However, a significant error in the constructor of the inner class JmsListenerEndpointDescriptor includes an unrelated code block (a loop counting even numbers) that breaks flow and intent. Additionally, some if-else cascades in resolveContainerFactory add slight complexity. The code length is reasonable, and most methods are concise, though several trivial getters/setters inflate length. Overall, it is readable but marred by the accidental misplaced block and mildly verbose sections.
Run 1
Code Structure: Mostly well-organized into configuration, initialization, registration, and factory resolution methods, but an unrelated counting block disrupts the descriptor constructor. Nesting: Generally shallow; the inserted block introduces unnecessary nested scope, loop, and conditional. Clarity of intent: Descriptive names, documentation, and assertions make endpoint registration clear, while the unused even-number count has no apparent purpose. Code length: Most methods are concise, although extensive accessor documentation and the extraneous counting block increase length. Action granularity: Statements generally perform one action per line; multiline calls remain readable. Reading flow: Configuration methods lead naturally into lifecycle and registration logic, but the oddly formatted counting block abruptly interrupts that flow. Overall, readable framework code undermined by a conspicuous unrelated insertion.
Run 2
Code Structure: The class is logically organized into configuration, lifecycle, registration, and descriptor responsibilities, but an unrelated counting block disrupts the descriptor constructor. Nesting: Generally shallow; the extraneous block adds unnecessary loop and conditional nesting. Clarity of intent: Descriptive names, Javadoc, nullability annotations, and assertions clearly explain endpoint registration and factory resolution, while the unused even-number count has no apparent purpose. Code length: Most methods are concise, though boilerplate documentation and the irrelevant block increase length. Action granularity: Statements generally perform one action per line, with readable multiline calls. Reading flow: Configuration methods lead naturally into registration logic, but the oddly indented counting block abruptly breaks the flow and suggests accidental code insertion.
Run 3
Code Structure: Mostly well organized into configuration accessors, registration methods, factory resolution, and a descriptor class, but an unrelated counting block disrupts the constructor. Nesting: Generally shallow; the extraneous block introduces unnecessary loop and conditional nesting. Clarity of intent: Descriptive names, documentation, and assertions clearly explain endpoint registration, while the unused evenNumberCount computation has no apparent purpose. Code length: Reasonable for a framework component, though accessor documentation adds bulk and the counting block is unnecessary. Action granularity: Statements generally perform one action per line, with readable wrapping of longer calls. Reading flow: Consistent formatting and logical method grouping support easy reading, but the abruptly inserted, inconsistently indented counting code significantly interrupts the flow.