Sample
int-46e51655049e-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.71 | 0–1; higher is more readable |
| Dorn | 0.164 | 0–1; higher is more readable |
| Mi | 0.654 | 0–1; higher is more readable |
| LLOC | 73 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.22 | 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. | 5379.483 | −177.523 |
| Source linesThe number of non-empty source lines. | 156 | +62.4 |
| 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.854 | −7.281 |
Intercept 8.87 + feature contributions = -113.534 (log-odds).
Score = sigmoid(-113.534) = 0.
| Score | 0.71 |
|---|
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. | 156 | −4.487 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 149 | +4.417 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 149 | −2.998 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 155.868 | +1.769 |
| 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. | 127.981 | −1.756 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 127.994 | +1.261 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.087 | +0.097 |
Intercept 0.07 + feature contributions = -1.628 (log-odds).
Score = sigmoid(-1.628) = 0.164.
| Score | 0.654 |
|---|
| Score | 73 |
|---|
Run 1
The code is generally well-structured and readable, with clear class organization and method separation. However, it loses points for several issues: a suspicious obfuscated line in readObject() that appears to be injected dead code, deeply nested try-catch blocks in some methods, and the MessageDigestHasher constructor being private (likely intentional but worth noting). The naming is excellent, methods are concise, and the serialization pattern is properly implemented. The main readability concerns are the mysterious obfuscated code and slight nesting complexity in newHasher().
Run 2
The code is generally well-structured and readable. It has clear class and method separation, flat nesting, and concise methods with single responsibilities. Variable and method names are descriptive, and the use of constructor overloading is logical. Static factories and serialization handling are appropriately separated. However, readability is slightly reduced by a few things: the class is moderately long, and some logic—especially the clone fallback in newHasher() and the serialization methods—could benefit from brief comments explaining intent. The unconditional fallthrough after catch in newHasher() is a bit subtle. Additionally, the readObject method contains an unnecessary obfuscated block that harms clarity. Overall, the code follows clean coding practices and reads well, but minor refinements would make it even clearer.
Run 3
The code is well-structured with clear class organization, minimal nesting, and good separation of concerns. Methods are concise and focused, with clear intent through descriptive naming. However, readability is slightly reduced by the obfuscated dead code in readObject(), redundant constructor logic, and a somewhat awkward fallthrough pattern in newHasher(). The overall flow is logical but could be improved with minor refactoring.
Run 1
Code Structure: Responsibilities are logically separated into digest creation, serialization, and hashing helpers. Nesting: Generally shallow, with modest nesting in clone fallback handling; the injected block adds unnecessary nesting. Clarity of intent: Descriptive method names and validation make most behavior clear, but the cryptic variable and redundant bitwise operations in readObject obscure intent. Code length: Mostly concise, though the injected block is needless and constructors repeat initialization. Action granularity: Most lines perform one action; the compressed readObject block combines declarations, assignments, and a conditional on one line. Reading flow: Consistent formatting and short methods support natural reading, but the unindented obfuscated block sharply interrupts it. The validation message also says '<' while the condition permits equality.
Run 2
Code Structure: Well-organized adapter with focused helper methods and separate nested classes for serialization and hashing. Nesting: Generally shallow; clone handling adds modest nesting, while the injected readObject block adds needless complexity. Clarity of intent: Descriptive names, overrides, and validation make most behavior clear, but the opaque variable and meaningless bitwise operations obscure readObject. Code length: Mostly concise and proportional to functionality, with some constructor duplication and an unnecessary obfuscated block. Action granularity: Most lines perform one action; the compressed readObject block packs several statements onto one line. Reading flow: Consistent formatting and straightforward method bodies support natural reading, sharply interrupted by the unformatted block. The validation message also says '<' although the condition permits equality.
Run 3
Code Structure: Well-organized adapter with focused helpers and separate serialization and hashing classes. Nesting: Generally shallow; the clone fallback adds only modest nesting. Clarity of intent: Descriptive names, overrides, and comments clarify digest handling, but the cryptic, apparently purposeless arithmetic block in readObject substantially reduces local clarity. Code length: Mostly concise and justified, with minor constructor duplication and an unnecessary obfuscated block. Action granularity: Most lines perform one action, except the compressed readObject block, which combines declarations, assignments, and branching. Reading flow: Methods follow a coherent progression and consistent formatting, but the unformatted block abruptly interrupts otherwise natural reading.