Sample
int-68395ab6afbb-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.006 | 0–1; higher is more readable |
| Scalabrino | 0.761 | 0–1; higher is more readable |
| Dorn | 0.842 | 0–1; higher is more readable |
| Mi | 0.699 | 0–1; higher is more readable |
| LLOC | 7 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs |
| BTTF | 0.7 | 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. | 553.182 | −18.255 |
| Source linesThe number of non-empty source lines. | 28 | +11.2 |
| 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.646 | −6.97 |
Intercept 8.87 + feature contributions = -5.155 (log-odds).
Score = sigmoid(-5.155) = 0.006.
| Score | 0.761 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 76.966 | +0.437 |
| 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. | 76.897 | +0.408 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.072 | +0.244 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 25 | +0.128 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 27.705 | −0.023 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 29 | +0.01 |
Intercept 0.07 + feature contributions = 1.672 (log-odds).
Score = sigmoid(1.672) = 0.842.
| Score | 0.699 |
|---|
| Score | 7 |
|---|
Run 1
The code is highly readable. It has a clear, logical structure with imports, class declaration, and concise method overrides. Nesting is minimal, with no nested blocks or conditionals. Each method expresses a single intent: reading data, flushing, and handling exceptions. Code length is appropriate for an echo handler — no unnecessary boilerplate. Action granularity is well-maintained, with one action per line (e.g., `ctx.write(msg)` and `cause.printStackTrace()`). Reading flow is natural: the class is named clearly, methods are ordered logically, and the Javadoc comment explains the class purpose. Minor deduction for the inline comment in `exceptionCaught` being slightly redundant, but overall the code is nearly exemplary.
Run 2
The code is well-structured with clear imports, a single-purpose class, and concise methods. It maintains flat nesting with no conditional blocks. Each method has a clear intent: reading, flushing, and exception handling. Action granularity is appropriate—one meaningful operation per line. The reading flow is natural, with methods ordered logically. Minor deductions include a missing blank line after the package statement before imports and the lack of a more informative comment for the exception handling (e.g., logging instead of printStackTrace). Overall, the handler is highly readable due to its simplicity and adherence to Netty conventions.
Run 3
The code is highly readable due to its clear, logical structure and minimal nesting. The class follows the standard Netty handler pattern, extending ChannelInboundHandlerAdapter with three concise methods that each perform a single, well-defined action. The @Sharable annotation and Javadoc comment clarify intent upfront. The reading flow is natural: import statements, class declaration, then method overrides in a sensible order (read, readComplete, exceptionCaught). There is no unnecessary verbosity—each line serves a purpose. Action granularity is good, with one primary operation per method. The only minor deduction is the side-effect `cause.printStackTrace()` in exceptionCaught, which is generally discouraged in production code but acceptable for an example. Overall, the code is almost exemplary in terms of readability.
Run 1
Code Structure: Three clearly separated event-handler methods provide logical organization. Nesting: No nested control flow; each method is flat. Clarity of intent: The class name, documentation, and standard callback names clearly communicate an SCTP echo handler, although the separate write and flush callbacks require some Netty familiarity. Code length: Compact, with no unnecessary implementation. Action granularity: Each statement performs one action on its own line. Reading flow: Methods progress naturally from receiving messages to flushing writes and handling exceptions. A blank line between the package declaration and imports would slightly improve visual separation.
Run 2
Code Structure: Cleanly organized into three focused event-handler methods. Nesting: Flat control flow with no nested logic. Clarity of intent: The class name, documentation, and standard callback names clearly communicate an SCTP echo handler; familiarity with Netty helps explain the separate write and flush operations. Code length: Concise, with no unnecessary logic or boilerplate beyond framework requirements. Action granularity: Each statement performs one action on its own line. Reading flow: Natural progression from receiving data to flushing output and handling exceptions. A blank line between the package declaration and imports would slightly improve visual separation.
Run 3
Code Structure: Imports, class documentation, and event-handler methods are logically organized. Nesting: Methods are flat, with no nested control flow. Clarity of intent: The class name, documentation, and standard callback names clearly communicate an SCTP echo server handler; separating write and flush assumes some Netty familiarity. Code length: The implementation is concise, with no unnecessary logic. Action granularity: Each statement performs one action on its own line. Reading flow: Methods follow a natural progression from receiving data to completing reads and handling exceptions. A blank line between the package declaration and imports would slightly improve visual separation.