Sample
int-87ef55c3eb1f-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.453 | 0–1; higher is more readable |
| Dorn | 0.756 | 0–1; higher is more readable |
| Mi | 0.442 | 0–1; higher is more readable |
| LLOC | 25 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 15.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.462 | 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. | 2825.028 | −93.226 |
| Source linesThe number of non-empty source lines. | 75 | +30 |
| 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.445 | −6.668 |
Intercept 8.87 + feature contributions = -61.024 (log-odds).
Score = sigmoid(-61.024) = 0.
| Score | 0.453 |
|---|
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. | 76 | −1.655 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 68 | +1.615 |
| 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. | 112 | −1.079 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 111.961 | +1.002 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 74.867 | +0.637 |
| 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 = 1.128 (log-odds).
Score = sigmoid(1.128) = 0.756.
| Score | 0.442 |
|---|
| Score | 25 |
|---|
Run 1
The code is generally readable but has some issues. The class structure is clear with a single field and two public methods. However, the 'all()' method is problematic: it uses a stream to collect failed partitions but then iterates over ALL values with a traditional loop, creating redundancy. This method could be simplified by filtering the entrySet once. The lambda callbacks in both methods are moderately nested (3 levels deep), slightly impacting readability. Clarity of intent is mostly good, but the error message construction in 'all()' is verbose and duplicated. Code length is acceptable for the functionality, though the 'all()' method is unnecessarily long due to the dual iteration approach. Action granularity is reasonable in most places, but the error handling in 'all()' packs multiple operations into single lines. The reading flow is natural in 'partitionResult()' but becomes choppy in 'all()' due to the mixed streaming and imperative styles.
Run 2
The code is generally well-structured with clear intent and good documentation. Classes and methods are logically organized, and imports are appropriate. Nesting is moderate: the partitionResult method uses a lambda with if-else branches, which remains readable. However, the all() method's loop over values could be simplified using streams for better clarity and conciseness. Action granularity is mostly one action per line, but some stream operations and exception throws could be broken down for improved readability. Reading flow is natural, with clear method names and comments explaining purpose. Minor issues include slightly verbose error handling in all() and a missed opportunity to use streams to find the first error, which would reduce nesting and improve readability further.
Run 3
The code demonstrates good structure with clear class and method separation. The nesting level is moderate, with lambdas and conditionals balanced effectively. Intent is generally clear through meaningful method names and Javadoc comments. The `partitionResult` method is concise and readable, though the `all()` method has slightly deeper lambda nesting and stream processing that requires careful reading. Code length is reasonable for the functionality provided. Action granularity is well-maintained with single logical operations per line. Reading flow is natural, following a logical progression from class structure through method implementations. Minor improvements could include extracting the complex lambda in `all()` to improve clarity further, but overall this is production-quality readable code.
Run 1
Code Structure: The class is logically organized around a shared future, with separate methods for partition-specific and aggregate results. Nesting: Moderate nesting in callbacks, especially the loop and conditional error handling in all(), slightly increases reading effort. Clarity of intent: Descriptive names, explicit completion paths, and Javadoc make the purpose clear, though returning null to complete a Void future requires familiarity with the API. Code length: Mostly concise, but duplicated exception construction and separate passes to collect failures and locate an error add some verbosity. Action granularity: Statements generally perform one action each; stream operations are clearly separated across lines. Reading flow: Constructor followed by individual and aggregate result methods provides a natural progression. Minor formatting inconsistencies and long exception expressions slightly interrupt an otherwise readable implementation.
Run 2
Code Structure: Well-organized result class with separate methods for partition-specific and aggregate outcomes. Nesting: Moderate nesting in asynchronous callbacks, particularly all(), slightly increases reading effort. Clarity of intent: Descriptive method names, types, and Javadoc make the purpose clear, although null-as-success semantics are implicit. Code length: Generally concise, but repeated exception construction and message formatting could be simplified. Action granularity: Statements largely perform one action each; the stream pipeline clearly separates filtering, mapping, and collection. Reading flow: Natural progression from state and constructor to result methods, with straightforward success/error handling. Minor formatting inconsistencies and the stream followed by a second traversal modestly interrupt an otherwise readable implementation.
Run 3
Code Structure: Well organized into a constructor and two focused public methods, with useful documentation. Nesting: Moderate nesting in asynchronous callbacks, particularly the loop and conditional branches in all(), adds some reading effort. Clarity of intent: Descriptive method names and explicit error handling make the purpose clear, though null representing success is implicit. Code length: Mostly concise, but repeated exception construction and message formatting could be simplified. Action granularity: Statements generally perform one action each; the stream pipeline separates transformations cleanly. Reading flow: Natural progression from partition-specific results to aggregate results, with consistent formatting overall. Minor spacing inconsistencies and the combination of a stream pass with a separate error-selection loop slightly interrupt readability.