Sample
int-7a99c744122b-I03
Replace method, parameter, and local names with length-matched, meaningful but unrelated names
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.654 | 0–1; higher is more readable |
| Dorn | 0.696 | 0–1; higher is more readable |
| Mi | 0.19 | 0–1; higher is more readable |
| LLOC | 33 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 8.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 9.33 | 0–20; mean of three runs |
| BTTF | 0.404 | 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. | 3778.701 | −124.697 |
| 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.934 | −7.401 |
Intercept 8.87 + feature contributions = -66.028 (log-odds).
Score = sigmoid(-66.028) = 0.
| Score | 0.654 |
|---|
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.938 | +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 |
| 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.056 | +0.394 |
Intercept 0.07 + feature contributions = 0.827 (log-odds).
Score = sigmoid(0.827) = 0.696.
| Score | 0.19 |
|---|
| Score | 33 |
|---|
Run 1
The code has a clear overall structure with a private constructor and static utility methods, but it is severely undermined by poor, misleading naming. Method names like `validateCache` and `validateSession` do not reflect their actual purpose of selecting methods; parameter names like `remotePath`, `defaultRequest`, `nextToken`, and `cachedScore` are nonsensical in this context and obscure the logic. This creates significant ambiguity and makes the intent very difficult to follow. The nesting is moderate but the boolean conditions within the `doWithMethods` callback are complex and hard to parse. Although the code is concise line-by-line and flat overall, the disorganized naming and complex conditional logic break the reading flow.
Run 2
The code has logical structure with clear class and method separation, and documentation is present. However, readability is significantly reduced by misleading and obfuscated variable/method names (e.g., 'validateCache' for method selection, 'remotePath' for a class type, 'defaultRequest' for a metadata lookup). The core logic contains moderately complex nested conditionals and a multi-clause boolean check that is hard to parse. Action granularity is generally one action per line, but the long conditional expression violates this. Reading flow is disrupted by names that do not convey intent. The code is concise but the obfuscated naming and dense logic make it difficult to follow without deep context.
Run 3
The code structure is logically organized into separate methods and includes helpful documentation. However, the naming conventions severely reduce readability. Variables such as 'remotePath', 'nextToken', 'defaultIndex', 'defaultSession', 'currentAccount', 'cachedScore', 'primaryAccount', 'window', and 'remoteBalance' have no conceptual relation to their actual purpose (target type, method map, candidate classes, etc.), making the intent extremely ambiguous. Nesting is moderate, but the complex conditional check for bridged methods is hard to follow. Code length is reasonable, though the method names ('validateCache', 'validateSession') are misleading. Action granularity is mostly one action per line, but the reading flow is disrupted by the cryptic naming. Overall, the structure and formatting are adequate, but the obfuscated names make the code difficult to understand and maintain.
Run 1
Code Structure: Well-separated utility methods and a callback interface provide logical organization. Nesting: Moderate nesting in the method-selection lambda and interface-search exception handling increases reading effort. Clarity of intent: Documentation explains the intended behavior, but misleading names such as validateCache, remotePath, and window obscure actual responsibilities. Javadoc parameter names do not match signatures, and calls to inspect conflict with the callback's declared publish method, making interpretation less reliable. Code length: Generally reasonable for the reflection logic, although extensive documentation and the compound bridge-method condition add bulk. Action granularity: Most statements perform one action per line; the filter overload compresses several operations into one expression. Reading flow: Formatting and sequential control flow are consistent, but unrelated identifiers, documentation mismatches, and the API inconsistency repeatedly interrupt comprehension.
Run 2
Code Structure: Well-separated utility methods and a callback interface provide logical organization. Nesting: Moderate nesting in the method-selection lambda and nested exception handling adds complexity. Clarity of intent: Severely weakened by misleading names such as validateCache, remotePath, and nextToken, which do not describe method introspection. Documentation references parameter names absent from the signatures, and calls to inspect conflict with the interface's declared publish method. Code length: Generally reasonable for the functionality, though extensive documentation and a long compound condition increase reading effort. Action granularity: Mostly one action per line, with a compact filter adapter and compound condition requiring closer attention. Reading flow: Consistent formatting and explanatory comments help, but mismatched naming and interface usage repeatedly interrupt comprehension.
Run 3
Code Structure: The utility class is logically divided into method-selection overloads, invocation resolution, and a callback interface. Nesting: Moderate nesting in loops, lambdas, conditionals, and nested try/catch blocks increases cognitive load. Clarity of intent: Misleading names such as validateCache, remotePath, and window obscure reflection-related responsibilities. Javadoc parameter names do not match signatures, and calls to inspect conflict with the callback's declared publish method, undermining comprehension and correctness. Code length: Implementation is reasonably concise, though extensive documentation and a long compound condition add reading overhead. Action granularity: Most statements perform one action per line, but the chained filtering overload and compound bridge-method checks compress several operations. Reading flow: Formatting and method grouping are consistent, yet unrelated identifiers and documentation inconsistencies force readers to repeatedly infer intended roles.