Sample
int-2ed925af62bb-I01
Remove line comments, block comments, and Javadoc
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.993 | 0–1; higher is more readable |
| Dorn | 0.535 | 0–1; higher is more readable |
| Mi | 0.689 | 0–1; higher is more readable |
| LLOC | 1 | 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.542 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 45 | +18 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 445 | −14.685 |
| 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.794 | −7.191 |
Intercept 8.87 + feature contributions = 4.994 (log-odds).
Score = sigmoid(4.994) = 0.993.
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. | 57.957 | +1.21 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 45 | +0.819 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 45 | −0.612 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 46 | −0.592 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 44.949 | +0.218 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.114 | −0.169 |
Intercept 0.07 + feature contributions = 0.141 (log-odds).
Score = sigmoid(0.141) = 0.535.
| Score | 0.689 |
|---|
| Score | 1 |
|---|
Run 1
The code is a simple, well-structured annotation definition with a clear purpose. It uses standard annotations logically, and the action granularity is clean—one attribute per line. However, readability is hurt by excessive blank lines both after the imports and inside the annotation body, which disrupts the reading flow and makes the file feel unnecessarily long. The deprecation is clear, and the overall intent is unambiguous.
Run 2
The code is highly readable due to its simple, clean structure. It is a single annotation definition with clear imports and meta-annotations. The nesting is flat, the intent is unambiguous (defining a deprecated 'Timed' annotation with a millis attribute), and the code is concise. Action granularity is appropriate—one annotation per line. The main readability issue is the excessive blank lines both between imports and the declaration, and within the annotation body, which disrupts the natural reading flow. Removing those extra blank lines would make it perfect.
Run 3
The code is highly readable despite excessive blank lines. The annotation structure is clear and logically organized with imports, annotations, and a single method. Nesting is nonexistent, intent is straightforward, and the code is concise. The main deduction comes from the unnecessary blank lines that disrupt reading flow, and the deprecated status could benefit from a javadoc explaining the replacement.
Run 1
Code Structure: Standard package, imports, annotations, and interface declaration provide clear organization. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Timed and millis convey a timing-related annotation, though the precise meaning of the millisecond value is undocumented. Code length: The implementation is concise, but excessive blank lines unnecessarily inflate its visual length. Action granularity: Each import, annotation, and member declaration occupies its own line. Reading flow: The declaration reads naturally, but large whitespace gaps interrupt the flow.
Run 2
Code Structure: The package, imports, annotations, and declaration follow a logical Java organization, but excessive blank lines weaken visual cohesion. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Timed and millis suggest a timing threshold, and the metadata clearly specifies applicability, runtime retention, and deprecation; however, documentation would clarify the timing semantics. Code length: The executable content is concise, but unnecessary whitespace greatly inflates the snippet. Action granularity: Each import, annotation, and member declaration occupies its own line. Reading flow: The declaration reads naturally once reached, but large empty gaps interrupt the flow.
Run 3
Code Structure: The package, imports, annotations, and declaration are logically ordered, but excessive blank lines weaken organization. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: Timed and millis clearly suggest a timing limit in milliseconds, though documentation would clarify its exact semantics. Code length: The functional code is concise, but unnecessary whitespace greatly inflates its visual length. Action granularity: Each import, annotation, and member declaration occupies its own line. Reading flow: The conventional Java layout is understandable, but large empty sections interrupt scanning.