Sample
int-0bd43c7f278d-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.649 | 0–1; higher is more readable |
| Dorn | 0.699 | 0–1; higher is more readable |
| Mi | 0.097 | 0–1; higher is more readable |
| LLOC | 44 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.43 | 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. | 4869.167 | −160.682 |
| Source linesThe number of non-empty source lines. | 116 | +46.4 |
| 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.754 | −7.131 |
Intercept 8.87 + feature contributions = -112.544 (log-odds).
Score = sigmoid(-112.544) = 0.
| Score | 0.649 |
|---|
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. | 117 | −3.106 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 103 | +2.826 |
| 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. | 134.94 | −2.05 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 133.803 | +1.354 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 115.912 | +1.21 |
| 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.083 | +0.14 |
Intercept 0.07 + feature contributions = 0.842 (log-odds).
Score = sigmoid(0.842) = 0.699.
| Score | 0.097 |
|---|
| Score | 44 |
|---|
Run 1
The code is highly readable with a clear, logical structure. The class hierarchy and field declarations are well-organized, and method implementations are concise. Nesting is minimal—only conditional/ternary and try-catch blocks are used. Intent is clear from descriptive method/field names and Javadoc. Action granularity is excellent: most operations take one line, except for concise one-liners in `configure` and `fromConnectData` that still remain readable. Reading flow is natural, with methods grouped by interface responsibilities. Minor deductions: the `cast` method suppresses a warning and has a potentially confusing generic T parameter; the `configure` method has a blank line before the closing brace; and the constructor uses assertions instead of explicit argument validation, which slightly obscures runtime intent.
Run 2
The code is highly readable with clear structure and purpose. The class is well-documented, fields are private final, and methods are logically grouped. Nesting is minimal with flat method implementations. Each method performs a distinct action with good granularity (e.g., configure methods call each other cleanly). Error handling is consistent and converts low-level exceptions to domain-specific exceptions with descriptive messages. The only minor deductions are for the assert statements which could be replaced with Objects.requireNonNull for clarity, and slight inconsistency in variable naming (conf vs configs). Overall, the code flows naturally from top to bottom and requires minimal effort to understand.
Run 3
The code demonstrates strong readability with clear class structure, minimal nesting (only in configure method), and concise methods. The class hierarchy and intent are well-documented with proper JavaDoc. Actions are generally one per line, and methods follow logical grouping (configure then serialize/deserialize then close). Minor deductions: the configure method with boolean parameter adds slight complexity, and the cast method could be more explicit about its purpose. Overall, this is production-quality code with good naming conventions and error handling.
Run 1
Code Structure: Fields, constructor, configuration, conversion, and cleanup methods are logically organized; header conversion delegates cleanly to data conversion. Nesting: Shallow try/catch blocks and no nested loops or conditionals keep complexity low. Clarity of intent: Descriptive names, interface overrides, and documentation explain the converter's purpose, null handling, and schema behavior. The unchecked cast and StringConverterConfig constant slightly obscure type and configuration relationships. Code length: Methods are short and focused, with little unnecessary code or duplication. Action granularity: Most lines perform one action; a few expressions combine casting, null handling, and serialization or deserialization with object construction, but remain understandable. Reading flow: Consistent method structure and straightforward delegation support natural reading. Minor formatting inconsistencies, long lines, and schema parameter shadowing slightly reduce readability.
Run 2
Code Structure: Fields, construction, configuration, conversion, and cleanup are logically organized; header methods reuse the main conversion methods. Nesting: Shallow try/catch blocks and simple expressions keep nesting minimal. Clarity of intent: Descriptive names, documentation, and contextual error messages make the converter's purpose clear. The unchecked cast and use of StringConverterConfig within a number converter introduce minor ambiguity. Code length: Concise methods and delegation avoid unnecessary duplication; documentation is proportionate. Action granularity: Each statement generally performs one action, though serialization combines null handling, casting, and invocation in one expression. Reading flow: Consistent formatting and straightforward method bodies support natural reading, with minor spacing inconsistencies and a long configuration expression slightly reducing polish.
Run 3
Code Structure: Well-organized fields, constructor, configuration, conversion, and cleanup methods; header conversion delegates cleanly to existing methods. Nesting: Minimal, limited to straightforward try/catch blocks. Clarity of intent: Descriptive names, interface overrides, and documentation make the converter's purpose clear, though the unchecked generic cast and StringConverterConfig constant require some contextual knowledge. Code length: Concise, with little duplication or unnecessary logic. Action granularity: Generally one action per line; inline null handling and object construction remain easy to follow. Reading flow: Methods follow a natural lifecycle, with consistent formatting overall. Minor spacing inconsistencies, long signatures and exception expressions, and schema parameter shadowing slightly reduce readability.