Sample
int-228f7be051ed-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.78 | 0–1; higher is more readable |
| Dorn | 0.813 | 0–1; higher is more readable |
| Mi | 0.405 | 0–1; higher is more readable |
| LLOC | 53 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.595 | 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. | 4066.04 | −134.179 |
| Source linesThe number of non-empty source lines. | 185 | +74 |
| 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.891 | −7.336 |
Intercept 8.87 + feature contributions = -58.645 (log-odds).
Score = sigmoid(-58.645) = 0.
| Score | 0.78 |
|---|
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. | 186 | −5.549 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 136 | +3.967 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 184.85 | +2.174 |
| 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.047 | +0.488 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 1.472 (log-odds).
Score = sigmoid(1.472) = 0.813.
| Score | 0.405 |
|---|
| Score | 53 |
|---|
Run 1
The code is well-structured with clear separation of concerns: configuration, registration, and descriptor storage. The class has a single responsibility and uses clear, descriptive method names. Nesting is minimal—only one level in the registerEndpoint and resolveContainerFactory methods. Javadoc comments effectively explain non-obvious behavior (like deferred factory resolution). The code is concise despite its length, with each method doing one clear thing. However, slightly reduced readability comes from some methods having multiple responsibilities (resolveContainerFactory has a factory caching side effect), and the registerAllEndpoints method triggers a side effect (setting startImmediately) that might not be obvious at first glance. The field ordering and grouping is logical. The use of separate descriptor class adds clarity. Overall, the code follows clean, maintainable patterns typical of well-written Spring configuration classes.
Run 2
The code is highly readable with clear structure and purpose. It follows standard Spring patterns with well-named fields, methods, and Javadoc. Nesting is minimal, mostly one level in conditionals and loops. Intent is clear from method names like 'resolveContainerFactory' and 'registerAllEndpoints'. Code length is appropriate, though some Javadocs are lengthy but informative. Action granularity is good, with one main operation per line. Reading flow is natural, with fields, setters/getters, lifecycle methods, then registration logic. Minor deductions: the conditional in 'resolveContainerFactory' could be slightly more concise, but the if-else chain is clear and each branch is short. Overall, excellent readability consistent with Spring Framework conventions.
Run 3
The code is well-structured with clear organization, following Spring conventions. The class has a single responsibility, methods are focused, and descriptive comments explain purpose and important design decisions. Nesting is minimal due to early returns and guard clauses; readability is strong except for the `resolveContainerFactory` method's slightly deep if-else chain. Action granularity and reading flow are mainly one action per line, but some multi-line string concatenations in exception messages reduce flow slightly. The code is concise and avoids unnecessary verbosity, though several lines exceed typical length preferences. The use of descriptive method and variable names removes ambiguity. The `registerEndpoint` method has minor branching but remains understandable. Overall, the code is highly readable and maintainable, with only minor issues preventing a perfect score.
Run 1
Code Structure: Logically organized into configuration accessors, lifecycle initialization, factory resolution, endpoint registration, and a small descriptor class. Nesting: Shallow loops and conditionals keep control flow easy to follow. Clarity of intent: Descriptive names, Javadoc, nullability annotations, and explicit assertions clearly communicate responsibilities and constraints; the lifecycle-dependent startImmediately flag requires some cross-method tracking. Code length: Implementation methods are concise, although extensive documentation and accessor boilerplate increase scanning length. Action granularity: Statements generally perform one action each, with multiline calls formatted clearly. Reading flow: Configuration naturally precedes initialization and registration logic, and factory fallback precedence is explicit. Minor friction comes from redundant else branches after returns and the factory resolver also caching a resolved factory.
Run 2
Code Structure: Well-organized fields, configuration accessors, lifecycle methods, registration logic, and a small descriptor class separate responsibilities clearly. Nesting: Shallow loops and conditionals keep control flow easy to follow; factory resolution uses a straightforward priority chain. Clarity of intent: Descriptive names, nullability annotations, assertions, and Javadoc explain configuration and registration behavior. The startImmediately flag introduces some lifecycle state that requires tracing across methods. Code length: Appropriate for its responsibilities, although accessor boilerplate and extensive documentation make the class longer to scan. Action granularity: Statements generally perform one action each, with clean formatting for multiline calls. Reading flow: Configuration leads naturally into initialization and registration, with factory resolution isolated in a helper. Minor interruptions come from lengthy type names, repeated registry assertions, and the placement of the factory-resolution helper before public registration methods.
Run 3
Code Structure: Well-organized fields, configuration accessors, lifecycle methods, registration logic, and a small descriptor class separate responsibilities clearly. Nesting: Shallow loops and conditionals keep control flow easy to follow. Clarity of intent: Descriptive names, Javadoc, nullability annotations, and explicit assertions explain configuration requirements and registration behavior; the lifecycle-dependent startImmediately flag requires some cross-method reading. Code length: Methods are concise, although extensive documentation and routine accessors make the class relatively long. Action granularity: Statements generally perform one action each, with wrapped calls remaining readable. Reading flow: Consistent formatting and a clear factory-resolution precedence support natural reading, though placing the resolution helper between registration methods slightly interrupts the flow.