Sample
int-0009184604d4-I01
Remove line comments, block comments, and Javadoc
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.744 | 0–1; higher is more readable |
| Dorn | 0.095 | 0–1; higher is more readable |
| Mi | 0.643 | 0–1; higher is more readable |
| LLOC | 69 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.338 | 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.741 | −7.112 |
Intercept 8.87 + feature contributions = -101.922 (log-odds).
Score = sigmoid(-101.922) = 0.
| Score | 0.744 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 154 | +4.59 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 154 | −4.416 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 154 | −3.113 |
| 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. | 0 | −0.804 |
| 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.088 | +0.084 |
Intercept 0.07 + feature contributions = -2.248 (log-odds).
Score = sigmoid(-2.248) = 0.095.
| Score | 0.643 |
|---|
| Score | 69 |
|---|
Run 1
The code is well-structured with clear separation of concerns: constructors, factory methods, serialization, and a private hasher class. Nesting is minimal, with only a few try/catch blocks and one conditional branch. Intent is clear, especially through method names like `supportsClone`, `checkNotDone`, and `writeReplace`. Code length is reasonable for the functionality. Action granularity is generally one action per line, and reading flow is natural. Some minor deductions: the empty catch block in `newHasher` is slightly ambiguous, and the two-argument constructor duplicates initialization logic; overall, it is highly readable.
Run 2
The code is well-structured with clear class separation between the hash function, serialization form, and hasher implementation. Methods are logically organized and follow a natural reading flow. Nesting is minimal, with only simple conditional blocks. Intent is clear through descriptive method and variable names, and each method has a single responsibility. Action granularity is appropriate, with one logical operation per line. The code is concise without unnecessary verbosity, though there are minor readability issues: the empty catch block in newHasher() looks suspicious, and the inline ternary in hash() could be slightly more readable if split. These are minor issues in an otherwise clean implementation.
Run 3
The code is well-structured with logical separation into serialization, hashing, and factory methods. Nesting is minimal, with only one level inside if/try-catch blocks. Class and method names clearly indicate intent. The code is concise yet complete, avoiding unnecessary verbosity. Action granularity is good—each logical step occurs on its own line. Reading flow is natural: constructors initialize fields, followed by utility methods, then nested classes. Minor deductions: the `supportsClone` method uses an awkward `unused` variable pattern, and the try-catch in `newHasher` has an empty catch block, slightly obscuring intent. Overall, highly readable for a security-sensitive library class.
Run 1
Code Structure: Responsibilities are logically separated into the hash function, serialization proxy, and digest hasher, with small focused methods. Nesting: Control flow is shallow; the nested classes and try/catch within an if remain manageable. Clarity of intent: Descriptive names and explicit state checks make the purpose clear, though the undocumented empty catch, unused clone result, and field named toString slightly obscure intent. The validation message also says '<' despite accepting the maximum length. Code length: Mostly concise, with minor constructor duplication and excessive blank lines. Action granularity: Statements generally perform one action per line; the final ternary combines digest generation and optional truncation but remains understandable. Reading flow: Methods follow a coherent progression, although inconsistent whitespace and the placement of serialization helpers mildly interrupt the flow.
Run 2
Code Structure: Responsibilities are logically separated into the hash function, serialization proxy, and hasher, with focused methods. Nesting: Mostly shallow; the cloning fallback introduces only modest nesting. Clarity of intent: Descriptive method names and explicit state checks make behavior clear, though the uncommented empty catch block and field named toString reduce clarity. The validation message also says '<' while the condition permits equality. Code length: Generally concise, with some constructor duplication and excessive blank lines. Action granularity: Statements usually perform one action per line; the final ternary packs digest generation, truncation, and wrapping into a denser expression. Reading flow: Consistent formatting and straightforward method bodies support natural reading, although whitespace noise and unexplained serialization mechanics slightly interrupt it.
Run 3
Code Structure: Responsibilities are logically separated into the hash function, serialization proxy, and digest hasher. Nesting: Mostly shallow; only the clone fallback introduces nested control flow. Clarity of intent: Descriptive method names and explicit state checks communicate purpose well, but the empty catch block leaves fallback behavior unexplained, and names such as bytes and toString are somewhat ambiguous. Code length: Methods are concise, although constructors duplicate initialization and excessive blank lines add visual noise. Action granularity: Statements generally perform one action per line; the final ternary combines digest generation, optional truncation, and wrapping. Reading flow: Consistent formatting and cohesive method groups make the code easy to follow, though serialization details interrupt the main hashing flow. The validation message also says '<' while the condition permits equality, creating a small clarity issue.