Sample
int-11f8ff4d4e1c-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.529 | 0–1; higher is more readable |
| Dorn | 0.626 | 0–1; higher is more readable |
| Mi | 0.561 | 0–1; higher is more readable |
| LLOC | 1 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19.33 | 0–20; mean of three runs |
| BTTF | 0.605 | 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. | 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.761 | −7.141 |
Intercept 8.87 + feature contributions = 0.118 (log-odds).
Score = sigmoid(0.118) = 0.529.
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. | 91.462 | +0.671 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.04 | +0.551 |
| 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. | 99 | −0.528 |
| 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. | 26 | +0.116 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 24.9 | −0.062 |
Intercept 0.07 + feature contributions = 0.514 (log-odds).
Score = sigmoid(0.514) = 0.626.
| Score | 0.561 |
|---|
| Score | 1 |
|---|
Run 1
The code is highly readable. It has a clear, logical structure with imports at the top, followed by a comprehensive Javadoc explaining the annotation's purpose and constraints. The annotation definition is minimal and focused. Nesting is flat, with no unnecessary complexity. Clarity of intent is excellent, with clear documentation about parameter requirements and serial invocation behavior. The code is concise, containing no redundant elements. Action granularity is appropriate, with each annotation on its own line. Reading flow is natural, from imports to documentation to implementation. Minor deductions only for unused imports (Target, RetentionPolicy are used indirectly but ElementType is fully qualified).
Run 2
The code is highly readable. It has a clear, logical structure with a single annotation declaration preceded by comprehensive Javadoc. Nesting is minimal and appropriate. Intent is unambiguous: defining a marker annotation for event subscriber methods. Code length is concise yet includes essential documentation and metadata. Action granularity is appropriate, with one annotation per line. Reading flow is natural, from package declaration through imports, Javadoc, annotations, and finally the interface declaration.
Run 3
This code is highly readable. The structure is logical: package declaration, imports, Javadoc, and annotations are cleanly organized. Nesting is nonexistent, as this is a simple annotation definition. The Javadoc clearly explains the intent, constraints, and behavior of the annotation. Code length is minimal and appropriate for its purpose. Each annotation is on its own line, maintaining clear action granularity. The reading flow is natural — documentation first, then metadata, then the declaration. A near-perfect example of concise, well-documented code.
Run 1
Code Structure: Package, imports, documentation, and annotation declaration are logically ordered. Nesting: The declaration is flat, with no nested logic. Clarity of intent: The Subscribe name and Javadoc clearly explain its purpose, parameter constraints, and concurrency behavior. Code length: The implementation is minimal, and the documentation adds useful context rather than unnecessary verbosity. Action granularity: Each import and annotation occupies its own line; the empty declaration is appropriately compact. Reading flow: The code progresses naturally from dependencies to explanation to declaration. Missing blank lines between the package, imports, and Javadoc slightly reduce visual separation.
Run 2
Code Structure: Standard Java organization cleanly separates the package, imports, documentation, metadata, and declaration. Nesting: No nested logic or control flow. Clarity of intent: The Subscribe name and detailed Javadoc clearly explain the annotation's purpose, parameter constraints, and concurrency behavior. Code length: The implementation is minimal, with documentation providing useful context rather than unnecessary verbosity. Action granularity: Each import and annotation occupies its own line, and the empty declaration is appropriately compact. Reading flow: The code progresses naturally from dependencies to explanation to annotation definition.
Run 3
Code Structure: Clearly organized into package declaration, imports, documentation, annotations, and declaration. Nesting: No nested logic; the empty annotation body is easy to scan. Clarity of intent: The Subscribe name and Javadoc clearly explain its purpose, parameter restrictions, and concurrency behavior. Code length: Concise implementation with useful documentation rather than unnecessary code. Action granularity: Each import and annotation appears on its own line. Reading flow: Natural top-to-bottom progression, though blank lines after the package declaration and imports would improve visual separation.