Sample
int-7a520feee2d7-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.815 | 0–1; higher is more readable |
| Dorn | 0.037 | 0–1; higher is more readable |
| Mi | 0.131 | 0–1; higher is more readable |
| LLOC | 64 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.436 | 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. | 5005.185 | −165.171 |
| Source linesThe number of non-empty source lines. | 297 | +118.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.724 | −7.086 |
Intercept 8.87 + feature contributions = -44.587 (log-odds).
Score = sigmoid(-44.587) = 0.
| Score | 0.815 |
|---|
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. | 298 | −9.515 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 168 | +5.074 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 296.832 | +3.739 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 168 | −3.434 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 97.98 | +0.776 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.035 | +0.606 |
| 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. | 99.953 | −0.568 |
Intercept 0.07 + feature contributions = -3.252 (log-odds).
Score = sigmoid(-3.252) = 0.037.
| Score | 0.131 |
|---|
| Score | 64 |
|---|
Run 1
This is highly readable production-quality code. Structure is clear: class docs, static factories, ACTIVE/Inactive implementations, then abstract API declarations. Nesting is minimal; anonymous ACTIVE and Inactive subclasses are small and focused. Intent is unambiguous—a fluent comparison chain that short-circuits. The code is concise, though the extensive Javadoc increases length; the executable portion remains tight. Action granularity is excellent, one logical operation per line. Reading flow is natural: constructor, start(), implementations, then abstract methods. Minor issues: obscure variable names (a,b,c,d,e,f) make `classify` and `result` slightly cryptic compared to the surrounding clarity; `classify` could use named constants like `LESS_RESULT/GREATER_RESULT`. The raw-type cast and suppression are justified with comments. Overloaded compare methods produce repetition, but this is inherent to the API design and aids type safety. Overall, exceptional readability for a utility class.
Run 2
The code is generally well-structured and follows clear patterns, but some oddities reduce readability. The class documentation is extensive and helpful, and the abstract method declarations are cleanly separated. However, the anonymous ACTIVE implementation contains confusing 'classify' and 'result' methods with meaningless variable names (a, b, c, d, e, f) that obscure intent—these could simply use explicit constants or direct comparisons. The use of arithmetic (a+b, c+d) instead of literal 0 is unnecessarily obfuscated. The InactiveComparisonChain class is straightforward and readable. Nesting is minimal, and method granularity is mostly one action per line. Overall flow is logical, but the deliberate obscurity in the active chain's core methods detracts from clarity.
Run 3
The code is well-structured with clear separation of concerns: an abstract base class defining the API, an ACTIVE implementation performing comparisons, and an InactiveComparisonChain short-circuiting after a result is determined. Documentation is thorough but verbose, somewhat impacting readability. Nesting is minimal, and intent is generally clear. However, the anonymous ACTIVE class contains obfuscated logic with meaningless variable names (a, b, c, d, e, f) and redundant expressions like `(a + b)` and `(e + f)`, reducing clarity. The deep inheritance hierarchy (ComparisonChain -> anonymous class -> InactiveComparisonChain) adds complexity. Action granularity is mostly good, but conditional logic in `classify` is compressed. Reading flow is natural at a high level but interrupted by excessive Javadoc and unclear numeric constants. Overall, readable but with notable clarity issues in the comparison logic.
Run 1
Code Structure: Active and inactive chain implementations are logically separated, with consistent overloads and a clear public API. Nesting: Control flow is shallow, although the anonymous class and nested ternary add some complexity. Clarity of intent: Descriptive method names and thorough documentation explain comparison behavior well; however, meaningless variables a–f and arithmetic expressions hiding zero obscure otherwise simple logic. Code length: Most methods are concise, but extensive documentation, repeated overloads, and unnecessary temporary constants increase reading effort. Action granularity: Statements generally perform one action per line; the classification ternary compresses multiple decisions into one expression. Reading flow: Formatting and method grouping are consistent, but placing implementation details before most API declarations and the artificial arithmetic interrupt an otherwise natural flow.
Run 2
Code Structure: Logically separates active comparisons, inactive states, and the public API, though the anonymous implementation adds some complexity. Nesting: Generally shallow; the nested ternary in classify is the main exception. Clarity of intent: Descriptive method names and thorough documentation explain chaining and short-circuit behavior, but meaningless variables a–f and arithmetic expressions obscure simple zero comparisons and returns. Code length: Individual methods are concise, while repeated overloads and extensive documentation make the file lengthy, mostly for legitimate API coverage. Action granularity: Statements generally perform one action per line; classify compresses multiple decisions into one expression. Reading flow: Consistent formatting and parallel method implementations aid scanning, but placing implementation details before abstract API declarations requires some navigation. Overall, readable and well documented, with avoidable obfuscation in two core methods.
Run 3
Code Structure: Logical separation of active and inactive comparison states, with a consistent public API. Nesting: Generally shallow; the anonymous implementation and nested class add modest complexity, while the nested ternary slightly impairs readability. Clarity of intent: Descriptive names, documentation, and examples explain the comparison chain well, but meaningless variables a–f and arithmetic expressions disguising zero obscure otherwise simple logic. Code length: Extensive documentation and repeated overloads make the file long, though most repetition supports the API; the extra constants are unnecessary. Action granularity: Statements generally perform one action per line, and methods remain small and focused. Reading flow: Consistent formatting and parallel implementations support predictable reading, but implementation details preceding abstract API declarations require some navigation, and the obfuscated classify/result methods interrupt the flow.