Sample
int-32935969a7ef-I10
Remove about 40% of line-break groups while retaining structure
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.187 | 0–1; higher is more readable |
| Dorn | 0.641 | 0–1; higher is more readable |
| Mi | 0.451 | 0–1; higher is more readable |
| LLOC | 1 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.593 | 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. | 351.862 | −11.611 |
| Source linesThe number of non-empty source lines. | 21 | +8.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.751 | −7.126 |
Intercept 8.87 + feature contributions = -1.468 (log-odds).
Score = sigmoid(-1.468) = 0.187.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 90.091 | +0.649 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.04 | +0.553 |
| 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. | 98.955 | −0.526 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 22 | +0.257 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 20.91 | −0.118 |
Intercept 0.07 + feature contributions = 0.581 (log-odds).
Score = sigmoid(0.581) = 0.641.
| Score | 0.451 |
|---|
| Score | 1 |
|---|
Run 1
The code is well-structured and highly readable. The Javadoc is clear and describes the annotation's purpose, constraints, and behavior effectively. The annotation declarations are concise and mostly organized, though the placement of multiple annotations on a single line slightly reduces readability. The class length is minimal, and intent is unambiguous. Overall, this is a clean, idiomatic Java annotation definition.
Run 2
The code is highly readable with clear structure and intent. The Javadoc is comprehensive and explains usage constraints well. Annotations are logically grouped, though @Keep shares a line with @Target, slightly reducing granularity. Imports are compressed onto fewer lines, which is concise but slightly unconventional. Overall, the single-purpose annotation is straightforward and easy to understand.
Run 3
The code is highly readable. It has a clear and logical structure, with imports appropriately placed and class-level annotations neatly arranged. Nesting is nonexistent, as this is a simple annotation definition. The intent is explicitly documented through comprehensive Javadoc, making the purpose of the @Subscribe annotation unambiguous. Code length is minimal and appropriate for an annotation type. Action granularity is excellent—each annotation and declaration is on its own line, with only import statements slightly condensed. Reading flow is natural: package declaration, imports, documentation, then annotations and declaration. The only minor readability issue is the multiple imports on a single line and the slightly cramped annotation grouping, but these are common Java style variations and don't significantly impact clarity.
Run 1
Code Structure: logically organized into package, imports, documentation, and annotation declaration, though spacing between sections would help. Nesting: entirely flat, with no complexity. Clarity of intent: the Subscribe name, metadata, and thorough Javadoc clearly explain its purpose and usage constraints. Code length: concise implementation with useful rather than redundant documentation. Action granularity: multiple imports share lines, and @Target, @Keep, and the declaration are compressed onto one line, reducing scanability. Reading flow: generally natural and conventional, but separating imports and annotations onto individual lines would improve readability.
Run 2
Code Structure: Logically organized as a package declaration, imports, documentation, and annotation definition, although compressed formatting weakens separation. Nesting: No nested logic; the empty annotation body is easy to understand. Clarity of intent: The Subscribe name, metadata annotations, and detailed Javadoc clearly explain its purpose and usage constraints. Code length: Concise, with documentation that adds useful context rather than unnecessary verbosity. Action granularity: Multiple imports share lines, and @Target, @Keep, and the declaration are combined on one line, reducing scanability. Reading flow: The overall order is natural, but separate import lines, spacing between sections, and one annotation per line would make reading smoother.
Run 3
Code Structure: Logically organized into package, imports, documentation, and annotation declaration. Nesting: No nested logic, making the code easy to scan. Clarity of intent: The Subscribe name, metadata, and detailed Javadoc clearly explain its purpose and usage constraints. Code length: Concise implementation with appropriately informative documentation. Action granularity: Multiple imports share lines, and @Target, @Keep, and the declaration are compressed onto one line, reducing visual separation. Reading flow: Generally natural, but missing spacing between sections and crowded declarations interrupt scanning. Separate imports and annotation lines would improve readability.