Sample
int-bb3a6731dbd5-I11
Split eligible integer literals into pairs of short-named intermediate variables
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 | 17.33 | 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 well-structured into clear methods with descriptive names, strong Javadoc, and logical separation of concerns. Nesting is minimal except in the bridge-method condition, which is slightly dense but still readable. Intent is clearly expressed through method and variable names like selectInvocableMethod and metadataLookup. The code is concise, avoids unnecessary verbosity, and generally maintains one action per line. Reading flow is natural, with the main algorithm in selectMethods flowing from type discovery to method iteration to metadata matching. The nested try/catch in selectInvocableMethod adds a bit of complexity but is handled with explanatory comments. Overall, this is professional, maintainable code with only minor readability challenges in the longest conditional.
Run 3
The code is well-structured and readable. It uses clear class and method names, concise Javadoc comments explaining intent, and a logical organization with a private constructor for a utility class. Nesting is generally shallow, though the first method contains a nested conditional with a multi-line boolean expression that is somewhat dense. Action granularity is mostly one action per line, and reading flow is natural. The main readability drawback is the complex bridge-method resolution condition, which requires careful reading to understand its purpose. Overall, the code is clear, maintainable, and follows Java conventions.
Run 1
Code Structure: Well-organized utility class with focused methods, a delegating overload, and a clearly defined callback interface. Nesting: Mostly moderate, but the loop/lambda/conditional combination and nested try/catch blocks increase cognitive load. Clarity of intent: Descriptive names and thorough Javadoc explain the API well; the compound bridge-method condition requires specialized knowledge and lacks a rationale comment. Code length: Implementation is reasonably concise; documentation is extensive but useful. Action granularity: Statements generally perform one action each, although the filter overload compresses casting, adaptation, selection, and key extraction into one expression. Reading flow: Consistent formatting, logical method order, and an early return support natural reading. Reflection and proxy-handling details introduce unavoidable complexity, while the abbreviated variable 'ifc' and dense boolean condition slightly reduce readability.
Run 2
Code Structure: Logically organized utility class with focused methods and a clearly separated callback interface. Nesting: Mostly manageable, though the loop/lambda/conditional sequence in selectMethods and nested try blocks in selectInvocableMethod require extra attention. Clarity of intent: Descriptive names and comprehensive Javadoc explain responsibilities well; the compound bridge-method condition is less immediately understandable. Code length: Implementation is reasonably concise for reflection and proxy handling, although documentation and the long exception message increase overall length. Action granularity: Most statements perform one action; the filter overload combines casting, a lambda, a ternary, delegation, and key extraction in one expression. Reading flow: Consistent formatting and sequential lookup logic support natural reading, with some interruption from complex conditions and exception-driven interface searching.
Run 3
Code Structure: Well-organized utility class with focused methods and a clearly separated callback interface. Nesting: Mostly manageable, though the loop, lambda, and nested conditionals in metadata selection require extra attention; nested try/catch blocks also add complexity. Clarity of intent: Descriptive names and thorough Javadoc explain the API well, but the bridge-method comparison logic is subtle and lacks an explanatory comment. Code length: Implementation is reasonably concise and reuses the metadata-selection method effectively; documentation is lengthy but useful. Action granularity: Generally one action per statement, with some compact expressions combining filtering, conversion, and result extraction. Reading flow: Consistent formatting, logical sequencing, and early returns support natural reading, although the compound bridge-method condition and exception-driven interface search interrupt the flow.