Sample
int-7a7b6ed539e7-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.679 | 0–1; higher is more readable |
| Dorn | 0.758 | 0–1; higher is more readable |
| Mi | 0.454 | 0–1; higher is more readable |
| LLOC | 33 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 7.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs |
| BTTF | 0.444 | 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. | 3765.02 | −124.246 |
| 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.916 | −7.374 |
Intercept 8.87 + feature contributions = -65.55 (log-odds).
Score = sigmoid(-65.55) = 0.
| Score | 0.679 |
|---|
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.808 | +1.586 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 96.639 | +0.755 |
| 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. | 97.986 | −0.485 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.06 | +0.363 |
Intercept 0.07 + feature contributions = 1.14 (log-odds).
Score = sigmoid(1.14) = 0.758.
| Score | 0.454 |
|---|
| Score | 33 |
|---|
Run 1
The code has decent high-level structure (class, methods, interface), but readability suffers from poor naming (method2, target3, method3, select2, met, met2), inconsistent naming patterns, and ambiguous variable names that obscure intent. Nesting is moderate, but the multi-line conditional with multiple `||` conditions is difficult to parse. Action granularity is acceptable overall, but some lines mix multiple actions (e.g., combining method resolution and lambda logic). Reading flow is disrupted by the abrupt variable numbering (target, target2, target3, target4) and duplicated logic in bridge-method resolution. The JavaDoc comments are helpful and clear, which partially mitigates the issues. Overall, the code functions but requires effort to understand due to naming and conditional complexity.
Run 2
The code has clear Javadoc and logical separation of methods, but readability is hampered by inconsistent and cryptic naming: method2, handler, target2/target3/target4, specific2, method3, met/met2. The select method mixes multiple operations within a single loop with long boolean conditions and deeply nested logic, reducing clarity. The second select method is concise but still has ambiguous parameter names. The select2 method is relatively straightforward but uses non-descriptive variable names as well. The file structure is typical, but overall clarity of intent and reading flow suffer due to naming and nested conditional logic.
Run 3
The code shows significant readability problems. Variable names are poor and inconsistent: 'target', 'target2', 'target3', 'target4', 'method', 'method2', 'method3', 'met', 'met2' - these numbered variants obscure intent. Method names like 'select2' and 'ins' are unclear. There's dead code: the variable 'specific' is only used in a null-check and assignment (target2 = specific != null ? specific : current), then never meaningfully used afterward, adding confusion. The main select method has moderate nesting with multiple conditionals and a complex bridged-method if statement combining four Boolean conditions on one line. Long lambda bodies reduce readability. The code does have logical grouping of methods and javadoc comments, which helps, but the cryptic naming, ambiguous purpose of variables, dead code, and inconsistent parameter/variable nomenclature make the implementation hard to follow and maintain. Structure and intent lose clarity due to these issues, outweighing the positive aspects of organizational structure and comments.
Run 1
Code Structure: Clearly separated methods and a small callback interface provide logical organization. Nesting: Moderate nesting in the traversal lambda and interface lookup adds complexity without becoming extreme. Clarity of intent: Detailed documentation helps, but vague numbered names such as method2, target3, and select2 obscure roles. Documentation parameter names do not match signatures, and calls to metadata.inspect conflict with the interface's ins method, undermining confidence in the intended behavior. Code length: Mostly proportionate to the reflection logic, though verbose documentation and the long bridge-method condition increase reading effort. Action granularity: Most statements perform one action, but the filter overload combines adaptation, selection, and key extraction in one expression. Reading flow: Consistent formatting and sequential lookup steps help, while ambiguous identifiers, nested exception handling, and the compound bridge condition interrupt comprehension.
Run 2
Code Structure: The utility class is logically organized into selection methods and a callback interface. Nesting: Moderate nesting in the method-scanning lambda and interface lookup adds complexity but remains manageable. Clarity of intent: Detailed documentation helps, but vague numbered names such as select2, target4, and specific2 obscure roles. Documentation parameter names do not match signatures, and calls to metadata.inspect conflict with the interface's ins method, making the intended API inconsistent. Code length: Reasonably concise for reflection and proxy handling, though documentation and the long exception message add bulk. Action granularity: Most lines perform one action; the filter overload and compound bridge-method condition require more unpacking. Reading flow: Consistent formatting and logical progression support readability, but inconsistent naming, nested exception handling, and the dense bridge-method predicate interrupt comprehension.
Run 3
Code Structure: Well-separated static methods and a callback interface provide logical organization. Nesting: Moderate nesting in the metadata-selection lambda and interface-search exception handling adds cognitive load. Clarity of intent: Documentation explains the purpose, but vague, numbered identifiers such as method2, target4, specific2, and select2 obscure roles. Javadoc parameter names do not match signatures, and calls to metadata.inspect conflict with the interface's declared ins method, making the intended callback usage confusing. Code length: Mostly proportionate to the reflection and proxy-handling logic, though documentation is verbose. Action granularity: Most lines perform one action; the chained selection expression and compound bridge-method condition are denser. Reading flow: Consistent formatting and sensible method ordering help, but inconsistent naming, mismatched documentation, and the long conditional interrupt otherwise natural progression.