Sample
int-1de46e47500d-I12
Inline all eligible single-use intermediate local variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.671 | 0–1; higher is more readable |
| Dorn | 0.843 | 0–1; higher is more readable |
| Mi | 0.324 | 0–1; higher is more readable |
| LLOC | 22 | 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.593 | 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. | 2474.179 | −81.648 |
| Source linesThe number of non-empty source lines. | 93 | +37.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.638 | −6.958 |
Intercept 8.87 + feature contributions = -42.536 (log-odds).
Score = sigmoid(-42.536) = 0.
| Score | 0.671 |
|---|
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. | 94 | −2.292 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 87 | +2.272 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 107.926 | +0.937 |
| 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. | 107.968 | −0.908 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 92.844 | +0.888 |
| 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.065 | +0.312 |
Intercept 0.07 + feature contributions = 1.677 (log-odds).
Score = sigmoid(1.677) = 0.843.
| Score | 0.324 |
|---|
| Score | 22 |
|---|
Run 1
The code is well-structured and readable. It uses a clean class layout with clear separation of constructors, static helpers, and instance methods. Nesting is minimal, with no deep conditional or logical blocks. The intent is mostly clear: representing a controller request context, converting timeouts to deadlines, and delegating quota application. Constructor overloads are concise and delegation via `this(...)` avoids duplication. Action granularity is mostly one action per line, though constructor chaining for `RequestHeaderData` is slightly dense but still readable. Naming is descriptive (`deadlineNs`, `partitionChangeQuotaApplier`) and the use of `OptionalLong` is appropriate. The static helper `requestTimeoutMsToDeadlineNs` is clear and concise. Minor reductions in readability come from the `__ -> { }` lambda (intent could be clearer with a named no-op) and the multiple delegating constructors, which may require a brief scan to understand. Overall, the code is maintainable and straightforward.
Run 2
The code is well-structured and readable. It uses clear naming conventions, demonstrates logical organization, and maintains flat nesting throughout. The constructor overloading with delegation reduces duplication effectively. The static helper method is concise and purpose-driven. While slightly verbose due to multiple constructors and a no-op lambda default, this is reasonable for the flexibility needed. The optional quota applier parameter is handled cleanly with default no-op implementations. Javadoc on the quota method clarifies intent. Overall, natural reading flow with one action per line.
Run 3
The code is well-structured with clear separation of concerns: static utility method, fields, constructors, and accessors. Nesting is minimal—only one chained builder in the AuthorizableRequestContext constructor. Intent is evident from descriptive names like 'partitionChangeQuotaApplier' and 'requestTimeoutMsToDeadlineNs'. Length is appropriate; the multiple constructors with delegation reduce duplication. Action granularity is good, with one operation per line in the builder and constructor assignments. Reading flow is natural: static method first, then fields, constructors, and methods. Minor deductions: the lambda parameter '__' is slightly unclear, and the static import of time constants could be marginally less readable than qualified names for some readers.
Run 1
Code Structure: Clearly organized around immutable fields, delegating constructors, accessors, and quota application, though placing the static utility before fields slightly interrupts conventional ordering. Nesting: Minimal nesting; constructor delegation and a fluent setter chain remain easy to follow. Clarity of intent: Descriptive names, explicit time units, and quota documentation communicate purpose well; the '__' lambda parameter and undocumented no-op default are minor ambiguities. Code length: Concise overall, with constructor overloads providing useful convenience rather than unnecessary duplication. Action granularity: Assignments and fluent setters occupy separate lines; the deadline calculation combines related operations in one understandable expression. Reading flow: Consistent formatting and straightforward delegation support natural reading, with minor friction from tightly grouped imports and the multiline header-building constructor call.
Run 2
Code Structure: Fields, delegating constructors, accessors, and quota handling are logically organized, though placing the static utility before fields slightly interrupts conventional ordering. Nesting: Minimal nesting keeps the code easy to scan. Clarity of intent: Descriptive names, explicit time units, and quota documentation clearly communicate purpose; the anonymous no-op lambdas could be more self-explanatory. Code length: Concise overall, with constructor overloads avoiding duplicated initialization. Action granularity: Assignments and builder calls each occupy separate lines; the deadline calculation combines related operations appropriately. Reading flow: Consistent formatting and straightforward delegation create a natural flow, with only minor friction from multiline constructor signatures and the chained header construction.
Run 3
Code Structure: Fields, delegating constructors, accessors, and quota application are logically organized, although placing the static helper before fields slightly interrupts conventional ordering. Nesting: Almost entirely flat, with no complex control flow. Clarity of intent: Descriptive names, explicit time units, and quota documentation communicate purpose well; the anonymous no-op lambdas are slightly less obvious. Code length: Concise overall, with constructor delegation avoiding duplicated initialization; overloads add some repetitive boilerplate. Action granularity: Assignments and chained header setters each occupy separate lines, making individual operations easy to follow. Reading flow: Consistent formatting and straightforward delegation create a natural progression, though tightly packed imports and the long deadline-conversion expression modestly reduce scanability.