Sample
int-b24637b7e2a9-I04
Replace method, parameter, and local names with deterministic ProGuard-style short identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.993 | 0–1; higher is more readable |
| Dorn | 0.687 | 0–1; higher is more readable |
| Mi | 0.471 | 0–1; higher is more readable |
| LLOC | 1 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs |
| BTTF | 0.686 | 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.832 | −7.247 |
Intercept 8.87 + feature contributions = 4.938 (log-odds).
Score = sigmoid(4.938) = 0.993.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.028 | +0.667 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 88.957 | +0.631 |
| 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.933 | +0.218 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 18 | −0.115 |
| 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. | 88.935 | −0.102 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 18 | +0.008 |
Intercept 0.07 + feature contributions = 0.786 (log-odds).
Score = sigmoid(0.786) = 0.687.
| Score | 0.471 |
|---|
| Score | 1 |
|---|
Run 1
The code demonstrates excellent readability. The package and imports are logically ordered. Javadoc is thorough yet clearly formatted with paragraph breaks and links. Annotations like @Target and @Retention are placed cleanly above the interface declaration. The single method 'millis()' is documented concisely, and the code is flat—no nesting or complex conditionals. Structure is minimal and purposeful, reflecting the nature of a simple annotation definition. Names are self-explanatory. While concise, the deprecation note is slightly long, but overall the code is very clear and easy to scan.
Run 2
The code is highly readable, with a clear and logical structure: imports are grouped, Javadoc is comprehensive, and annotations are organized. There is no nesting or complex logic, as this is an annotation definition. The intent is unambiguous—defining a test timeout. The code is concise, with one action per line in the annotation declaration. Reading flow is natural, moving from documentation to metadata to the method signature. Minor deductions for slight verbosity in the Javadoc, but overall, it is a model of clean, well-documented Java code.
Run 3
The code is highly readable due to its clear structure and purpose. It is a simple annotation definition with a logical organization: package declaration, imports, Javadoc, annotations, and the interface body. Nesting is minimal—essentially flat. The Javadoc is thorough and explains intent, usage, deprecation, and references clearly. The annotation is concise, containing only one method, and action granularity is straightforward (one annotation per line where appropriate). Reading flow is natural: metadata annotations precede the interface, followed by the single member. Minor deductions: the long Javadoc may be verbose for a deprecated annotation, but it provides necessary historical and migration context. Overall, excellent clarity and maintainability.
Run 1
Code Structure: Logically organized into package, imports, documentation, annotations, and a single declaration. Nesting: Minimal, with only the annotation body. Clarity of intent: Timed and millis() clearly express the purpose, while documentation explains timeout scope, usage, and deprecation. Code length: The implementation is concise; the longer documentation provides useful context rather than unnecessary complexity. Action granularity: Each import, metadata annotation, and member declaration occupies its own line. Reading flow: Natural top-to-bottom progression with consistent formatting. A blank line between the package declaration and imports would slightly improve visual separation.
Run 2
Code Structure: Standard Java organization cleanly separates imports, documentation, annotation metadata, and the declaration. Nesting: Minimal nesting, with only one member inside the annotation. Clarity of intent: Timed and millis(), supported by precise Javadoc, clearly express the timeout purpose, units, scope, and deprecation status. Code length: The implementation is concise; documentation is longer but provides useful context rather than unnecessary repetition. Action granularity: Each import, annotation, and member declaration occupies its own line. Reading flow: Natural top-to-bottom progression makes the code easy to scan. A blank line between the package declaration and imports would slightly improve visual separation.
Run 3
Code Structure: Imports, documentation, annotation metadata, and the interface declaration are logically organized. Nesting: Only one shallow declaration scope, with no nested control flow. Clarity of intent: Timed and millis(), supported by precise Javadoc, clearly communicate the timeout purpose, units, scope, and deprecation status. Code length: The implementation is minimal; documentation is longer but provides useful context rather than unnecessary repetition. Action granularity: Each import, annotation, and member declaration occupies its own line. Reading flow: The code progresses naturally from context to metadata to the single configuration member. Minor formatting issues, such as the missing blank line after the package declaration and the extra blank line before the closing brace, slightly reduce polish.