Sample
int-80163f1071a2-I12
Inline all eligible single-use intermediate local variables
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 | 17.33 | 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 with clear structure, logical organization, and consistent naming conventions. It follows Java standards with proper static imports, field declaration, constructor chaining, and method grouping. The class has a single responsibility—adapting MessageDigest to the HashFunction interface—and uses clear method names like supportsClone, checkNotDone, and readResolve. Nesting is minimal, with only necessary try-catch blocks. Action granularity is generally one action per line, though some lines combine operations (e.g., ternary in hash()). The reading flow is natural: fields, constructors, utility methods, overrides, and inner classes appear in a predictable order. Serialization logic is properly isolated in SerializedForm, enhancing readability. Minor deductions: the clone fall-through logic in newHasher() is slightly subtle, and some methods could be broken up slightly, but overall the code is exemplary for a utility class.
Run 3
The code is generally readable, with clear class and method names, consistent formatting, and logical organization. It separates concerns into nested classes for serialization and hashing. The code is mostly flat, with nesting limited to try-catch blocks, and each action is clearly separated into lines. Intent is clear from method names like `checkNotDone` and `supportsClone`. However, readability is slightly reduced by a few factors: variable names like `bytes` and `toString` are generic, and the `newHasher` method has a fallthrough pattern with a comment that interrupts flow. Some methods (e.g., `supportsClone`) are concise but could be clearer with null checks. Overall, it is well-structured but not maximally readable.
Run 1
Code Structure: Well-organized constructors, focused helper methods, and nested classes separate hashing from serialization. Nesting: Mostly flat, with only modest nesting in the clone fallback. Clarity of intent: Descriptive names, overrides, and validation make the adapter's purpose clear; the field named toString and specialized serialization conventions require some interpretation. Code length: Concise overall, though constructors and update methods contain minor repetition. Action granularity: Statements generally perform one action per line; the final conditional expression combines digest generation, truncation, and wrapping but remains manageable. Reading flow: Consistent formatting and short methods support natural reading, although serialization code interrupts the transition from hash-function setup to hasher implementation. Minor distractions include the unused clone result and an error message saying '<' where validation permits '<='.
Run 2
Code Structure: Responsibilities are cleanly separated into digest creation, serialization, and a nested hasher implementation. Nesting: Control flow is shallow, with only a modestly nested clone attempt. Clarity of intent: Descriptive methods, explicit state checks, and brief comments make the adapter's purpose clear; names such as bytes and toString are slightly less precise, and the validation message says '<' while the condition allows equality. Code length: Methods are concise, with reasonable repetition in constructors and update overloads. Action granularity: Most lines perform one action; the final hash expression combines digest generation, optional truncation, and wrapping. Reading flow: Consistent formatting and focused methods support natural reading, though serialization machinery interrupts the progression from hash-function setup to hashing behavior.
Run 3
Code Structure: Well-organized adapter with separate nested classes for serialization and hashing, plus focused helper methods. Nesting: Mostly shallow; the conditional try/catch in newHasher adds only modest complexity. Clarity of intent: Descriptive names, overrides, validation, and comments make responsibilities clear. Minor distractions include the toString field name, unused clone result, and a validation message saying '<' where the condition allows equality. Code length: Appropriately concise; constructor and update-method repetition is limited and understandable. Action granularity: Statements generally perform one action per line; the final ternary combines digest creation and optional truncation but remains readable. Reading flow: Consistent formatting and short methods support natural reading, although serialization boilerplate interrupts the flow between factory logic and hashing implementation.