Sample
int-0dfcd8bf6a57-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 1 | 0–1; higher is more readable |
| Scalabrino | 0.928 | 0–1; higher is more readable |
| Dorn | 0.581 | 0–1; higher is more readable |
| Mi | 0.226 | 0–1; higher is more readable |
| LLOC | 13 | 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.717 | 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. | 77 | +30.8 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 529.661 | −17.479 |
| 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.253 | −6.38 |
Intercept 8.87 + feature contributions = 15.811 (log-odds).
Score = sigmoid(15.811) = 1.
| Score | 0.928 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 77 | −1.69 |
| 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. | 118.962 | −1.374 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 119 | +1.116 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.014 | +0.807 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 76.842 | +0.664 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 31 | +0.335 |
Intercept 0.07 + feature contributions = 0.326 (log-odds).
Score = sigmoid(0.326) = 0.581.
| Score | 0.226 |
|---|
| Score | 13 |
|---|
Run 1
The code is well-structured with a clear class purpose and logical organization. It uses flat nesting, minimal lines, and one action per line. Javadoc comments thoroughly explain parameters and return values, making intent unambiguous. The constructor and getters follow natural reading flow, and the use of Objects.requireNonNull is concise and clear. Minor deductions for verbose comments slightly increasing length, but overall the code is highly readable.
Run 2
This code is highly readable. It has a clear, logical class structure with fields, constructor, and accessor methods. Nesting is minimal, with only basic class and method blocks. The intent is explicit through comprehensive Javadoc, which clearly explains parameters, edge cases, and time values. Although the Javadoc is lengthy, it documents non-obvious behavior (e.g., nullability, time semantics) appropriately. Each constructor assignment and return statement is on its own line, improving clarity. The reading flow is natural: fields, constructor, then getters. Minor deductions are for slight verbosity in repeated Javadoc and missing class-level summary, but overall the code is easy to understand and maintain.
Run 3
The code demonstrates excellent readability across all criteria. Structure is logical: fields, constructor, then accessors in a natural order. No nesting or control flow exists, keeping the code flat and easy to follow. Intent is clearly conveyed through descriptive method names and comprehensive Javadoc, especially for the context of re-authentication. Code length is appropriate — no unnecessary lines or overengineering, just a simple immutable data holder. Action granularity is ideal: each line performs one clear action, particularly in the constructor. Reading flow feels natural, mirroring how a developer would explain the class: 'what it holds,' 'how it's built,' 'how to access it.' The only minor deduction is for slightly verbose Javadoc on simple getters, but this is consistent with Apache Kafka project standards and not a flaw in the code itself.
Run 1
Code Structure: Logically organized into immutable fields, a constructor, and simple accessors. Nesting: Flat methods with no nested control flow. Clarity of intent: Descriptive names and detailed documentation clearly explain re-authentication state, nullability, and timing semantics. Code length: Implementation is concise, though repeated documentation about networkReceive and timing makes the class longer than necessary. Action granularity: Each statement performs one clear action, including explicit null validation. Reading flow: Conventional Java organization and consistent formatting make the code easy to follow; minor field/constructor ordering differences and verbose comments slightly interrupt the flow.
Run 2
Code Structure: A logically organized context class with private final fields, a constructor, and straightforward accessors. Nesting: Flat implementation with no nested control flow. Clarity of intent: Descriptive names and thorough documentation clearly explain re-authentication state, nullability, and timestamp semantics. Code length: The implementation is concise, but repeated, lengthy Javadoc adds unnecessary bulk. Action granularity: Each assignment and return occupies its own line, making individual operations easy to follow. Reading flow: The conventional fields–constructor–accessors sequence is natural and consistent; minor distractions include the long constructor signature and documentation repetition.
Run 3
Code Structure: Clearly organized into immutable fields, a constructor, and simple accessors. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive names and documentation explain re-authentication context, nullability, and timing semantics. Code length: Implementation is concise, though repeated, lengthy Javadoc adds unnecessary reading overhead. Action granularity: Each statement performs one clear action, including explicit non-null validation. Reading flow: Natural progression from state definition to initialization and accessors; minor formatting issues, such as no blank line after the package declaration and a long constructor signature, slightly reduce polish.