Sample
int-92e5c59c69fb-I06
Invert eligible conditions and exchange their branches
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.33 | 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. It has a clear, logical structure with imports, Javadoc, annotations, and the interface declaration all logically separated. Nesting is minimal—only the package and annotation declaration exist, with no nested logic. The intent is explicit through comprehensive Javadoc that explains the annotation's purpose, usage, deprecation status, and time constraints. The code is concise, avoiding unnecessary verbosity while maintaining clarity. Action granularity is appropriate, with each element on its own line. Reading flow is natural, progressing from package declaration through metadata to the core definition. Minor deductions: the deprecation notice is lengthy, and the single method's Javadoc slightly overlaps with class-level documentation.
Run 3
This is an exceptionally readable Java annotation definition. The structure is logical: package, imports, Javadoc, annotations, then the interface. Nesting is non-existent. Intent is crystal clear—the Javadoc thoroughly explains the purpose, usage, and deprecation. Code length is appropriate for an annotation definition with rich documentation. Action granularity is ideal, with one import/concept per line. The reading flow is natural: you understand what the code does before seeing it, thanks to the comprehensive documentation, then the metadata annotations provide usage context, and finally the single method declaration is self-explanatory. Minor deduction only because the Javadoc is somewhat lengthy for simple code, but this is a documentation best practice, not a readability flaw.
Run 1
Code Structure: Standard Java organization cleanly separates imports, documentation, annotation metadata, and the declaration. Nesting: Essentially flat, with only one member inside the annotation. Clarity of intent: Timed and millis() clearly convey a test execution time limit; documentation explains scope, units, and deprecation. Code length: Implementation is minimal; extensive Javadoc is relevant, though slightly verbose relative to the declaration. Action granularity: Each import, annotation, and member declaration occupies its own line, making individual elements easy to scan. Reading flow: Natural top-to-bottom progression from context to configuration to the single parameter. Minor formatting improvements, such as a blank line after the package declaration, would further improve readability.
Run 2
Code Structure: Logically organized into imports, documentation, annotation metadata, and a single member. Nesting: Essentially flat, with only the interface body. Clarity of intent: The Timed name, millis() member, and detailed Javadoc clearly explain the timeout semantics, scope, and deprecation. Code length: The implementation is minimal; documentation is somewhat lengthy but provides useful context. Action granularity: Each import, annotation, and member declaration occupies its own line. Reading flow: Follows conventional Java ordering and is easy to scan, though a blank line between the package declaration and imports would improve separation.
Run 3
Code Structure: Standard Java organization clearly separates imports, documentation, annotation metadata, and the declaration. Nesting: Essentially flat, with only the annotation body. Clarity of intent: The Timed name, millis() member, and detailed documentation clearly explain the timeout, its scope, and deprecation. Code length: The implementation is minimal; documentation is longer but 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 makes the code easy to scan. Minor formatting improvements, such as a blank line after the package declaration and removing the extra blank line before the closing brace, would improve polish.