Sample
Remove line comments, block comments, and Javadoc
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.589 | 0–1; higher is more readable |
| Dorn | 0.648 | 0–1; higher is more readable |
| Mi | 0.732 | 0–1; higher is more readable |
| LLOC | 1 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 19.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs |
| BTTF | 0.562 | 0–1; higher is more readable |
Loading feature diagnosis…
| 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. | 25 | +10 |
| 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.598 | −6.898 |
Intercept 8.87 + feature contributions = 0.361 (log-odds).
Score = sigmoid(0.361) = 0.589.
| 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. | 45.808 | +1.725 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.11 | −0.131 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 26 | +0.116 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 24.936 | −0.061 |
Intercept 0.07 + feature contributions = 0.609 (log-odds).
Score = sigmoid(0.609) = 0.648.
| Score | 0.732 |
|---|
| Score | 1 |
|---|
The code is highly readable. It has a clear, logical structure with standard package and import declarations, followed by annotations and a simple interface declaration. Nesting is non-existent, and the intent of defining a runtime-retained method annotation for event subscription is unambiguous. The code is concise and performs one action per line, especially with each annotation on its own line. Minor deductions are for the excessive blank lines between imports and the annotation, which slightly disrupts reading flow, and for the empty interface body being on the same line as the declaration, which is a minor deviation from one-action-per-line.
The code is a model of clarity and conciseness. It follows a standard Java annotation definition structure with a logical organization: package declaration, focused imports, then the annotation type. There is no nesting, and the intent is immediately obvious—defining a runtime, method-level annotation for event subscription. It is extremely short with zero redundancy. The few annotations are placed one per line, and the reading flow is natural and straightforward. The blank lines, while numerous, do not obscure the straightforward declaration and may simply be a byproduct of the original file's formatting.
The code is a minimal annotation definition with a clear, single purpose. Structure is logical: imports, annotations, then declaration. Nesting is nonexistent, and the intent is immediately obvious—marking methods as event subscribers. Length is perfectly concise. Each annotation is on its own line, maintaining clean action granularity. Reading flow is natural and standard for Java. The only minor issue is excessive blank lines, but this does not affect readability.
Code Structure: The package, imports, annotations, and declaration are logically organized, though excessive blank lines disrupt formatting. Nesting: There is no nesting, making the code easy to scan. Clarity of intent: The Subscribe name and runtime retention with a method target clearly convey a method-level subscription marker. Code length: The implementation is minimal, but unnecessary whitespace adds visual length. Action granularity: Each import and annotation occupies its own line; the empty declaration appropriately fits on one line. Reading flow: The declaration reads naturally, but the large blank gap between imports and annotations interrupts the flow.
Code Structure: The package, imports, annotations, and declaration are logically ordered, but excessive blank lines disrupt grouping. Nesting: There is no nesting beyond the empty annotation body. Clarity of intent: Subscribe clearly names the annotation, and its runtime retention and method target are explicit. Code length: The implementation is minimal, though unnecessary whitespace adds visual length. Action granularity: Each import and annotation occupies its own line; the compact empty declaration is appropriate. Reading flow: The ordering is natural and easy to follow, but the large gap between imports and annotations interrupts scanning.
Code Structure: The package, imports, annotations, and declaration are logically ordered, though excessive blank lines weaken organization. Nesting: There is no nested logic, making the code easy to scan. Clarity of intent: Subscribe clearly represents a method-level annotation retained at runtime; @Keep adds preservation intent. Code length: The implementation is minimal, but unnecessary whitespace lengthens its presentation. Action granularity: Each import and annotation occupies its own line; the empty declaration is appropriately compact. Reading flow: The ordering is natural, but the large gap before the annotations interrupts otherwise smooth reading.