Sample
int-72386cd36bc2-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.546 | 0–1; higher is more readable |
| Dorn | 0.778 | 0–1; higher is more readable |
| Mi | 0.282 | 0–1; higher is more readable |
| LLOC | 50 | 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.379 | 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. | 4610.646 | −152.151 |
| Source linesThe number of non-empty source lines. | 129 | +51.6 |
| 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.973 | −7.459 |
Intercept 8.87 + feature contributions = -99.141 (log-odds).
Score = sigmoid(-99.141) = 0.
| Score | 0.546 |
|---|
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. | 130 | −3.567 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 116 | +3.275 |
| 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. | 123.977 | −1.586 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 128.864 | +1.391 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 123.985 | +1.196 |
| 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.089 | +0.079 |
Intercept 0.07 + feature contributions = 1.257 (log-odds).
Score = sigmoid(1.257) = 0.778.
| Score | 0.282 |
|---|
| Score | 50 |
|---|
Run 1
The code is highly readable with clear structure and intent. It follows a logical organization: constructor, interface methods, main conversion logic, helper methods, and an inner class. Nesting is shallow, with only one level inside the loop and conditionals. Action granularity is appropriate, with mostly one action per line. Reading flow is natural, guiding the reader from type checks through conversion to map creation. The use of helper methods (canConvertKey, convertKey, etc.) improves clarity and reduces duplication. The 'Shortcut if possible...' comment clarifies the early return. Minor deductions: the convert method is somewhat long but still coherent, and the MapEntry inner class adds slight overhead but is well-encapsulated. Overall, the code is concise, well-documented, and easy to follow.
Run 2
The code is well-structured, with a clear class name, logical method organization, and helpful comments. Nesting is minimal (one loop, simple conditionals), making the flow easy to follow. Intent is evident throughout, especially through method names like canConvertKey, convertValue, and the MapEntry helper. Length is appropriate — concise without sacrificing clarity. Each line performs a single action, enhancing readability. The reading flow is natural, progressing from validation to conversion to result creation. Minor deductions for the slightly verbose MapEntry class and repeated pattern in convertKey/convertValue, but overall very readable.
Run 3
The code is well-structured with clear separation of concerns: type checking, conversion, and helper methods. Nesting is minimal, with only one level in the main loop and early returns reducing complexity. Intent is clearly expressed through descriptive method names and a helpful class-level comment. The code is concise—helper methods avoid duplication and keep the main conversion method focused. Action granularity is appropriate, with one logical operation per line. Reading flow is natural: edge cases first, then processing, then map construction. Minor deductions: the MapEntry inner class adds slight indirection for simple key-value storage, and the use of nullability annotations, while beneficial, adds visual noise. Overall, this is highly readable production-quality code.
Run 1
Code Structure: Well organized into interface methods, focused conversion helpers, and a small entry holder. Nesting: Shallow loops and conditionals, with early returns keeping complexity low. Clarity of intent: Descriptive names and class documentation clearly communicate map conversion; reference comparisons and deferred map creation require slightly more thought. Code length: Reasonably concise, although parallel key/value helpers and the MapEntry class add modest verbosity. Action granularity: Statements generally perform one action per line, making conversion steps easy to follow. Reading flow: Natural progression from null handling and shortcut checks through element conversion to target-map construction. Consistent formatting supports scanning, though some long signatures and extra blank lines slightly reduce compactness.
Run 2
Code Structure: Well organized into conversion logic, focused helper methods, and a small entry class. Nesting: Shallow conditionals and loops, with early returns keeping control flow flat. Clarity of intent: Descriptive names and class documentation clearly explain map conversion; reference-identity comparisons and deferred copying require slightly more thought. Code length: Generally concise, though separate key/value helpers and the intermediate MapEntry class add some boilerplate. Action granularity: Statements mostly perform one action per line, making individual operations easy to follow. Reading flow: Natural progression from null handling and shortcut checks through element conversion to target-map creation; the two-pass conversion strategy adds modest cognitive overhead.
Run 3
Code Structure: Well organized into converter methods, focused helpers, and a small entry holder. Nesting: Shallow loops and conditionals, with early returns keeping control flow flat. Clarity of intent: Descriptive names and class documentation clearly explain map conversion; identity comparisons and copyRequired require some thought to understand the reuse optimization. Code length: Mostly concise, though parallel key/value helpers and the intermediate MapEntry class add modest verbosity. Action granularity: Statements generally perform one action per line; longer conversion calls remain understandable. Reading flow: Natural progression from validation through element conversion to map creation, with consistent formatting. The two-pass approach slightly interrupts the flow, and a comment explaining deferred allocation would improve readability.