Sample
int-100043cd5706-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.66 | 0–1; higher is more readable |
| Dorn | 0.697 | 0–1; higher is more readable |
| Mi | 0.17 | 0–1; higher is more readable |
| LLOC | 33 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.514 | 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. | 3736.929 | −123.319 |
| Source linesThe number of non-empty source lines. | 143 | +57.2 |
| 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.917 | −7.376 |
Intercept 8.87 + feature contributions = -64.625 (log-odds).
Score = sigmoid(-64.625) = 0.
| Score | 0.66 |
|---|
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. | 143 | −4.027 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 93 | +2.48 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 142.912 | +1.588 |
| 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.986 | −1.078 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 111.965 | +1.002 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.056 | +0.398 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.831 (log-odds).
Score = sigmoid(0.831) = 0.697.
| Score | 0.17 |
|---|
| Score | 33 |
|---|
Run 1
The code is well-structured and highly readable. It has a clear, logical organization with a private constructor enforcing utility class semantics. Javadoc comments are comprehensive and explain intent. Nesting is controlled: the main selectMethods method uses a single for-loop and a lambda, avoiding deep indentation. The selectInvocableMethod has a try-catch with a nested try-catch inside a loop, but it is handled cleanly with explanatory comments. Intent is clear from method and variable names. Code length is concise; the bridge method resolution condition is complex but unavoidable for the domain. Each line performs a single logical action, improving clarity. Reading flow is natural, moving from broad utility methods to specific lookup logic. Overall, this is an excellent example of readable Spring framework code.
Run 2
The code is generally well-structured, with clear separation of public methods, a private constructor, and a nested functional interface. Class-level Javadoc clearly explains the purpose. However, the `selectMethods` method contains a long, complex conditional chain for bridge method resolution that is difficult to parse quickly. The `selectInvocableMethod` method also has somewhat tangled logic with nested try/catch blocks and a 'final desperate attempt' comment. While comments and formatting are good, the deep conditional logic and multi-step action sequences reduce readability. The use of descriptive variable names and constant usage improves clarity, but some sections could be refactored into smaller helper methods for better action granularity and flow.
Run 3
The code is generally well-structured and readable. Methods are logically organized, and Javadoc comments clearly explain intent. Nesting is minimal; the core logic in selectMethods uses one lambda with a single conditional containing a complex boolean expression, which slightly impacts clarity. Naming is descriptive. Length is appropriate for the complexity. Action granularity is mostly one operation per line, though the multi-line boolean condition in the lambda and the chained selectMethods/methodFilter conversion are slightly dense. Reading flow is natural due to clear method separation and comments. Minor deductions for the complex bridge-method condition and the somewhat obscure selectMethods lambda.
Run 1
1. Code Structure: Well-organized utility class with focused methods, a reusable overload, and a clearly defined callback interface. 2. Nesting: Mostly manageable, though the loop/lambda/conditional combination and nested exception handling require extra attention. 3. Clarity of intent: Descriptive names and thorough Javadoc explain metadata selection and proxy handling; the compound bridge-method condition is less immediately understandable. 4. Code length: Implementation is reasonably concise for its functionality, although documentation and the lengthy exception message increase visual length. 5. Action granularity: Most statements perform one action; the filter overload combines adaptation, delegation, and result extraction in one expression. 6. Reading flow: Consistent formatting, early returns, and sequential fallback logic support natural reading. Specialized reflection utilities, a terse 'ifc' variable, and subtle bridge-method comparisons slightly interrupt the flow.
Run 2
Code Structure: Logically organized utility class with distinct method-selection operations and a clearly defined callback interface. Nesting: Mostly moderate, but the loop/lambda/nested conditionals in metadata selection and nested try blocks in invocable-method lookup increase cognitive load. Clarity of intent: Descriptive names and thorough Javadoc explain the API well; bridge-method identity/equality checks and proxy handling require specialized knowledge and could benefit from explanatory comments. Code length: Generally concise for its responsibilities, with some verbose documentation and exception text that provide useful context. Action granularity: Statements generally perform one action each, although the filter overload combines callback adaptation, method selection, and key-set extraction in one expression. Reading flow: Natural progression from setup through traversal to results, with consistent formatting and helpful early returns; the long compound bridge-method condition slightly interrupts the flow.
Run 3
Code Structure: Well-organized utility class with focused methods, a reusable overload, and a clearly separated callback interface. Nesting: Mostly moderate, but the loop/lambda/conditional combination in metadata selection and nested try blocks in invocable-method lookup increase cognitive load. Clarity of intent: Descriptive names and thorough Javadoc explain the purpose well; the compound bridge-method condition requires specialized knowledge and could use an explanatory comment. Code length: Implementation is reasonably concise for its reflection and proxy-handling responsibilities, although documentation occupies substantial space. Action granularity: Most statements perform one action; the filter overload combines casting, a lambda, delegation, and key extraction in one expression. Reading flow: Consistent formatting and logical progression from type discovery to inspection and result collection make the code easy to follow overall. Dense conditions and exception-driven interface searching slightly interrupt that flow.