Sample
int-f51dbd51a1da-I13
Lower every eligible classic and enhanced for loop to a while loop
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.752 | 0–1; higher is more readable |
| Dorn | 0.324 | 0–1; higher is more readable |
| Mi | 0.654 | 0–1; higher is more readable |
| LLOC | 69 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.348 | 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. | 5008.496 | −165.28 |
| Source linesThe number of non-empty source lines. | 154 | +61.6 |
| 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.765 | −7.148 |
Intercept 8.87 + feature contributions = -101.958 (log-odds).
Score = sigmoid(-101.958) = 0.
| Score | 0.752 |
|---|
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. | 154 | −4.416 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 147 | +4.347 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 147 | −2.952 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 153.887 | +1.741 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 95.948 | +0.744 |
| 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. | 95.961 | −0.399 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.084 | +0.13 |
Intercept 0.07 + feature contributions = -0.735 (log-odds).
Score = sigmoid(-0.735) = 0.324.
| Score | 0.654 |
|---|
| Score | 69 |
|---|
Run 1
The code is highly readable with excellent logical organization. The class structure is clear: an outer hash function adapter and an inner hasher implementation, with serialization concerns cleanly separated in a nested SerializedForm class. Nesting is minimal—only one level in the newHasher try/catch and in the hash() ternary. Each method has a single, clear purpose, and the intent is obvious from names like checkNotDone, supportsClone, and getMessageDigest. Lines are concise and actions are well-separated; constructors validate arguments and assign fields cleanly. The reading flow is natural, moving from construction to hashing to serialization. The static imports for checkArgument, checkNotNull, and checkState reduce verbosity without sacrificing clarity. The only slight complexity is the fall-through catch block in newHasher, but the comment 'falls through' makes the intent explicit. Overall, this is an exemplary model of readable production code.
Run 2
The code is highly readable, well-structured, and follows clear conventions. It organizes related functionality into logical sections (constructors, static helpers, serialization, inner class). Nesting is shallow, with only a few try-catch blocks and conditionals. Intent is clear: adapting MessageDigest to Guava's HashFunction API. Code length is appropriate, avoiding unnecessary verbosity while maintaining clarity. Each line typically performs one action, improving comprehension. The reading flow is natural, moving from construction to hashing to serialization. Minor deductions: the clone fallback logic in newHasher is slightly non-obvious, and the conditional ternary in hash() could be slightly more readable, but these are minor and do not significantly impact overall clarity.
Run 3
The code is well-structured with clear separation of concerns: constructors, static helpers, serialization handling, and the nested Hasher implementation. Nesting is minimal, with only one level of indentation in conditional blocks. Intent is generally clear - each method has a single purpose, and naming is descriptive. Action granularity is good, with most lines performing a single action. The reading flow is logical: fields, constructors, overrides, helpers, then the nested Hasher. Minor readability drawbacks include the use of a try-catch to probe clone support, which is slightly indirect, and the dual constructors create some redundancy. The method overriding is clean and the serialization handling is well-commented. Overall, this is production-quality readable code, losing only a few points for slight complexity around the cloning logic and constructor duplication.
Run 1
Code Structure: Well-organized adapter with separate nested classes for serialization and hashing. Nesting: Shallow control flow; the clone fallback introduces only modest nesting. Clarity of intent: Descriptive method names, explicit state checks, and focused comments make behavior clear, though the toString field name and unused clone variable are slightly awkward. Code length: Mostly concise, with minor duplication between constructors and update methods. Action granularity: Statements generally perform one action per line; the final conditional expression combines digest computation, truncation, and wrapping but remains understandable. Reading flow: Consistent formatting and small methods support natural reading, although serialization helpers interrupt the progression from adapter creation to hashing implementation. Overall, highly readable with minor naming and flow issues.
Run 2
Code Structure: Responsibilities are logically separated into the hash-function adapter, serialization proxy, and digest hasher, with small focused methods. Nesting: Generally shallow; the clone attempt inside a conditional adds only modest complexity. Clarity of intent: Descriptive method names, explicit validation, and lifecycle checks clearly communicate behavior. Minor distractions include the toString field name, unused clone result, and a validation message saying '<' when the condition permits equality. Code length: Appropriate for the functionality, though constructors and update methods contain some repetition. Action granularity: Almost every statement performs one action; the final conditional expression combines digest generation, optional truncation, and wrapping but remains manageable. Reading flow: Consistent formatting and straightforward control flow make the code easy to follow, although serialization machinery interrupts the transition from factory behavior to hashing implementation.
Run 3
Code Structure: Responsibilities are logically separated into the hash-function adapter, serialization proxy, and digest hasher, with small, focused methods. Nesting: Generally shallow; only the cloning fallback adds modest nested control flow. Clarity of intent: Descriptive method names, explicit state checks, and brief comments clearly explain behavior. Minor distractions include the field named toString, an unused clone result, and a validation message saying '<' when the condition permits equality. Code length: Appropriate for the functionality, although constructors and update methods contain some repetition. Action granularity: Most statements perform one action per line; the final conditional expression combines digest generation, optional truncation, and wrapping but remains understandable. Reading flow: Consistent formatting and straightforward method bodies support natural reading. Serialization machinery interrupts the main hashing flow slightly, and imports could benefit from visual grouping.