Sample
int-7e1a39c53da0-SRC
Unmodified source class
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 | 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 readable. It uses clear method names, Javadoc, and logical organization. Nesting is moderate; the main method has a loop with a callback but remains understandable. The bridge method resolution condition is complex and somewhat ambiguous, slightly reducing clarity of intent. Code length is appropriate, and action granularity is mostly one action per line. Reading flow is natural due to the top-down structure and explanatory comments. Overall, it is highly readable with minor complexity in the bridge method condition.
Run 2
The code is well-structured with clear class-level organization, separate methods, and Javadoc for public APIs. Nesting is moderate—the lambda inside a loop inside a method is acceptable, but the bridge-method condition is somewhat dense and hard to parse at a glance. Intent is mostly clear from method names and comments, though the bridge-method logic lacks explanatory comments. Code length is reasonable, but some conditions could be extracted into helper methods for clarity. Action granularity is mostly one action per line, but the long conditional and `String.format` block add slight noise. Reading flow is generally natural: class definition, methods in logical order, and helper interface at the end. Minor issues: the empty `catch` block is acceptable here but slightly unusual, and the `selectMethods` method has multiple responsibilities (type resolution, filtering, mapping). Overall, very readable with only small readability improvements possible.
Run 3
The code is well-structured and highly readable overall. It follows a logical organization with clear separation of concerns, minimal nesting, and concise method bodies. Intent is clearly communicated through meaningful method names and solid Javadoc. Each line generally performs one action, and the reading flow is natural. The only notable issue is the bridge method resolution condition in selectMethods, which is somewhat dense and potentially ambiguous, slightly reducing clarity. Additionally, the inner lambda and multi-condition boolean expression increase cognitive load, but not excessively. Overall, the code is maintainable and clear.
Run 1
Code Structure: Well-organized utility class with focused methods, a delegating overload, and a clearly separated callback interface. Nesting: Mostly manageable, although the loop/lambda/conditional combination and nested exception handling add complexity. Clarity of intent: Descriptive method names and thorough Javadoc explain the purpose; the bridge-method condition is technically dense and lacks an explanation of its rationale. Code length: Implementation is reasonably concise for reflection and proxy handling, though documentation adds substantial length. Action granularity: Most statements perform one action; the filter overload compresses casting, lambda logic, delegation, and result extraction into one expression. Reading flow: Consistent formatting, early return, and logical search progression support natural reading, with minor friction from the compound condition and exception-driven interface lookup.
Run 2
Code Structure: Logically organized into focused utility methods and a clearly defined callback interface. Nesting: Mostly manageable, but the loop/lambda/conditional combination in metadata selection and nested try blocks in invocable-method lookup require extra attention. Clarity of intent: Descriptive method names and thorough Javadoc explain the purpose well; bridge-method comparisons and reflection-specific behavior are less immediately intuitive. Code length: Implementation is reasonably concise for its responsibilities, though documentation is extensive and the compound bridge-method condition is dense. Action granularity: Most statements perform one action; the filter overload combines adaptation, delegation, and key-set extraction in one expression. Reading flow: Consistent formatting and logical progression make the code easy to follow, with minor interruptions from long conditions, exception-driven lookup, and specialized proxy terminology.
Run 3
Code Structure: Cohesive utility class with clearly separated selection methods and a small callback interface. Nesting: Generally manageable, though the loop/lambda/conditional combination and nested try blocks require extra attention. Clarity of intent: Descriptive method names and thorough Javadoc explain the API well; the compound bridge-method condition and abbreviated 'ifc' variable are less immediately clear. Code length: Implementation is reasonably concise and reuses the metadata-based selector, although documentation and the 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 orderly setup, traversal, and return paths support natural reading, with reflection-specific logic and exception-driven interface searching introducing some friction.