Sample
int-b7e1492f9055-I10
Remove about 40% of line-break groups while retaining structure
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.663 | 0–1; higher is more readable |
| Dorn | 0.03 | 0–1; higher is more readable |
| Mi | 0.001 | 0–1; higher is more readable |
| LLOC | 69 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.155 | 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. | 100 | +40 |
| 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.821 | −7.231 |
Intercept 8.87 + feature contributions = -123.641 (log-odds).
Score = sigmoid(-123.641) = 0.
| Score | 0.663 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 217.95 | −5.566 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 217.99 | +2.713 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 101 | −2.54 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 93 | +2.48 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 93 | −1.713 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 99.863 | +0.986 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.086 | +0.107 |
Intercept 0.07 + feature contributions = -3.464 (log-odds).
Score = sigmoid(-3.464) = 0.03.
| Score | 0.001 |
|---|
| Score | 69 |
|---|
Run 1
This code is difficult to read due to severe formatting issues. Multiple statements are packed onto single lines (e.g., package declaration with imports, field declarations like 'private final int bytes; private final boolean supportsClone;', and method bodies). This violates the one-action-per-line principle and creates visual clutter. The indentation is inconsistent, with some blocks properly indented but others flattened. Nesting is moderate in the newHasher() method with try-catch inside an if-else. While variable names are descriptive (prototype, supportsClone, toString), the dense formatting obscures the code's intent. The class structure is logical, but reading flow is severely disrupted by the compressed layout. The code would be much more readable with standard formatting, each statement on its own line, and consistent indentation.
Run 2
The code suffers from severe readability issues. Multiple statements are compressed onto single lines, violating the 'one action per line' principle. Import statements are not properly separated, and class structure is cramped with methods and fields intertwined without clear visual separation. Nesting depth is moderate but made worse by inline conditional logic. The intent of the class (adapting MessageDigest to HashFunction) is recognizable, but the implementation details are obscured by formatting choices. There are several long chains of statements that could be broken into logical blocks. The reading flow is disrupted by inconsistent line breaks and brace placement, forcing the reader to visually parse dense clusters rather than naturally scanning the code. While the overall architecture is logical, the formatting choices undermine clarity significantly.
Run 3
The code suffers from excessive line compression, with multiple statements crammed onto single lines, making it hard to follow. Imports are collapsed into one long line, fields are grouped together without spacing, and methods like `supportsClone` and `newHasher` have poor formatting. The structure itself is logical, but the visual presentation destroys readability. Nesting is moderate but made worse by the formatting. Intent is somewhat clear from class names and comments, but the dense style obscures it. Length is reasonable but not concise due to compression. Action granularity fails badly - multiple actions per line throughout. Reading flow is severely disrupted by the inconsistent spacing and line breaks. While the underlying code quality is decent, the formatting makes it unnecessarily difficult to read. A proper reformat would significantly improve the score.
Run 1
Code Structure: Responsibilities are logically separated into digest creation, hashing, and serialization, but compressed formatting obscures class and method boundaries. Nesting: Generally shallow; newHasher adds moderate nesting through an if and try/catch. Clarity of intent: Descriptive class and method names, validation calls, and comments make the adapter's purpose understandable, though the field named toString is less clear. Code length: Implementation is reasonably concise without substantial unnecessary code, but excessive line compression reduces readability. Action granularity: Multiple imports, declarations, assignments, and method boundaries frequently share lines, making individual operations harder to scan. Reading flow: The overall organization is sensible, but inconsistent indentation, inline annotations, and crowded braces interrupt natural top-to-bottom reading.
Run 2
Code Structure: Responsibilities are logically separated into the hash function, serialization proxy, and hasher, but compressed formatting obscures boundaries. Nesting: Mostly shallow, with manageable nested conditional and try/catch logic in newHasher. Clarity of intent: Descriptive class and method names, validation checks, and comments make the purpose clear; the bytes parameter shadowing a field adds minor ambiguity. Code length: Reasonably concise with little unnecessary code, though excessive compression sacrifices readability. Action granularity: Many lines combine imports, declarations, assignments, methods, or control-flow transitions, making individual actions harder to scan. Reading flow: Inconsistent line breaks, inline annotations, and closing braces followed immediately by new methods interrupt natural reading. Overall, sound organization and clear intent are substantially undermined by formatting.
Run 3
Code Structure: Constructors, helper methods, serialization support, and hashing behavior are logically separated, but compressed formatting obscures these boundaries. Nesting: Generally shallow; the nested if/try/catch in newHasher is manageable but difficult to scan. Clarity of intent: Descriptive class and method names, standard API usage, and comments make the purpose clear, although the field named toString is slightly confusing. Code length: Reasonably concise with little unnecessary logic; excessive line compression reduces readability rather than improving concision. Action granularity: Multiple imports, declarations, assignments, and method boundaries share lines, frequently violating one-action-per-line presentation. Reading flow: Inconsistent indentation, inline braces, and annotations attached to neighboring methods interrupt otherwise natural progression. Overall, the underlying design is readable, but poor formatting substantially increases reading effort.