Sample
int-6faa2414d93b-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.84 | 0–1; higher is more readable |
| Dorn | 0.667 | 0–1; higher is more readable |
| Mi | 0.085 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.562 | 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. | 3071.679 | −101.365 |
| Source linesThe number of non-empty source lines. | 162 | +64.8 |
| 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.575 | −6.862 |
Intercept 8.87 + feature contributions = -34.558 (log-odds).
Score = sigmoid(-34.558) = 0.
| Score | 0.84 |
|---|
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. | 163 | −4.735 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 107 | +2.964 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 161.86 | +1.853 |
| 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. | 119.945 | −1.415 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 115.656 | +1.062 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.045 | +0.501 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.697 (log-odds).
Score = sigmoid(0.697) = 0.667.
| Score | 0.085 |
|---|
| Score | 50 |
|---|
Run 1
The code is well-structured with clear logical organization: fields, listener, constructors, public API methods, and private helpers are grouped sensibly. Nesting is generally flat, with the deepest level being three (listener -> operationComplete -> executor.execute -> Runnable), which is acceptable. Intent is explicit through meaningful names and thorough Javadoc. Code length is appropriate, though some deprecated overloads add slight verbosity. Action granularity is mostly one action per line, enhancing readability. Reading flow is natural, with public methods following constructors and private helpers at the end. Minor issues: the listener's nested Runnable slightly increases depth, and raw type usage with @SuppressWarnings detracts slightly from clarity.
Run 2
The code is well-structured with clear separation of concerns, clean field declarations, and logically grouped methods. Nesting is minimal—only a two-level anonymous listener and a single conditional block—keeping the flow flat and readable. Intent is highly explicit through Javadocs, method names, and assertions. Code length is concise and proportional to functionality, with no unnecessary duplication. Action granularity is mostly one action per line, improving readability. The reading flow is natural, moving from field declarations to constructors, public API methods, and private helpers. Minor deductions: the listener's anonymous inner class introduces slight indirection, and the tryPromise method is terse. Overall, this is a clean, maintainable implementation.
Run 3
The code is well-structured with clear separation of fields, constructors, public methods, and private helpers. Javadoc comments explain intent and thread-safety constraints. Methods are concise and mostly one action per line. There is little nesting—only a couple of levels inside the listener and loops. Naming is consistent and descriptive. Minor readability weaknesses: the inner listener class has a nested Runnable and a private method, adding slight complexity. The addAll(Future...) method delegates to add(), which calls checkInEventLoop() each time—slightly repetitive but not harmful. Raw-type casts and suppressions reduce clarity slightly. Overall, the code is easy to follow and maintain.
Run 1
Code Structure: Well-organized class with focused methods and separate validation helpers; the listener placed among fields slightly interrupts organization. Nesting: Most methods are flat, but nested anonymous listener and Runnable classes add visual depth. Clarity of intent: Descriptive names and comprehensive documentation clearly explain aggregation, failure handling, and threading requirements; raw types and the operationComplete0 name slightly reduce clarity. Code length: Implementation methods are concise, although repeated documentation and deprecated overloads increase overall length. Action granularity: Statements generally perform one action per line, making state changes easy to follow. Reading flow: Consistent formatting and straightforward checks support natural reading, though asynchronous callback dispatch requires tracing between the listener, completion helper, and promise resolution method.
Run 2
Code Structure: Well-organized class with small public methods and focused validation helpers, though the listener embedded among fields slightly interrupts organization. Nesting: Most methods are flat; nested anonymous listener and Runnable classes add localized complexity. Clarity of intent: Descriptive names and comprehensive documentation clearly explain aggregation, failure handling, and threading constraints; operationComplete0 and tryPromise are less descriptive. Code length: Implementation is concise, but repetitive documentation and deprecated overloads increase reading overhead. Action granularity: Statements generally perform one action per line, with a compact, understandable conditional expression for promise completion. Reading flow: Public operations follow a natural add-then-finish lifecycle, supported by consistent formatting; understanding asynchronous completion requires jumping between the listener, counters, and helper methods.
Run 3
Code Structure: Well-organized class with small public methods and focused validation helpers; the large anonymous listener slightly interrupts the layout. Nesting: Most methods are flat, although the listener's nested Runnable adds visual depth. Clarity of intent: Descriptive names and thorough documentation clearly explain aggregation, failure handling, and thread requirements; tryPromise is less explicit, and raw types reduce clarity. Code length: Implementation is concise, but repeated documentation and deprecated overloads increase reading overhead. Action granularity: Statements generally perform one action per line, making state changes easy to follow. Reading flow: Adding futures, tracking completion, and finishing aggregation follow a logical progression, though understanding asynchronous completion requires moving between the listener, finish, and tryPromise.