Sample

int-bb4f2138b42b-I10

Remove about 40% of line-break groups while retaining structure

Matched original source

Lines11

Scores

MethodScoreScale
Posnett0.5090–1; higher is more readable
Scalabrino0.9670–1; higher is more readable
Dorn0.8410–1; higher is more readable
Mi0.4180–1; higher is more readable
LLOC3Logical lines; fewer is more readable
DeepSeek V4 Pro14.670–20; mean of three runs
GPT-6.1 Sol13.670–20; mean of three runs
BTTF0.6630–1; higher is more readable

Views

Source code

package com.google.common.cache; import com.google.common.annotations.GwtCompatible; /** * Abstract interface for objects that can concurrently add longs. * * @author Louis Wasserman */ @GwtCompatible interface LongAddable { void increment(); void add(long x); long sum(); }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
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.703−7.055
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.187.296−6.181
Source linesThe number of non-empty source lines.11+4.4

Intercept 8.87 + feature contributions = 0.034 (log-odds).
Score = sigmoid(0.034) = 0.509.

Score0.967

Feature contributions

FeatureValueContribution
(log-odds)
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.65.833+0.877
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.12+0.611
Indentation frequencyHow rapidly indentation changes from line to line.7−0.495
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.66+0.26
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.10.806−0.259
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.076+0.205

Intercept 0.07 + feature contributions = 1.668 (log-odds).
Score = sigmoid(1.668) = 0.841.

Score0.418
Score3
Run 1

The code is highly readable due to its clear structure, flat hierarchy, and concise expression. The interface is logically organized with a package declaration, an import, and a well-documented Javadoc comment that clarifies intent. There is no unnecessary nesting, and each method declaration is a single action, contributing to a natural reading flow. The code is not overly verbose; it provides only the essential contract for a long adder. The minor deductions are for slight formatting inconsistencies, such as multiple methods on one line and the closing brace on the same line as the last method, which could slightly disrupt scanning. Overall, the code is clean, purposeful, and easy to understand.

Run 2

The code is short and functional but poorly formatted. Its structure is logical (interface with three methods), but the formatting violates standard conventions: methods are on the same line, the Javadoc and import are crammed together, and the closing brace has inconsistent spacing. Nesting is non-existent, which is good. Clarity of intent is acceptable — method names are clear — but the lack of formatting makes it harder to scan. Code length is concise, but excessive for the trivial amount of content. Action granularity is poor: multiple method declarations are on one line, reducing readability. Reading flow is disrupted by the absence of line breaks. With proper formatting, this would score much higher.

Run 3

The code has clear intent and is logically structured overall, but its formatting harms readability. The package declaration and import are on one line, documentation is crammed alongside the import and interface declaration, and multiple method signatures share the same line. This violates one-action-per-line and interrupts natural reading flow. The structure is simple and the code is concise, but nesting is shallow and intent remains clear despite the poor layout.

Run 1

Code Structure: The package, import, documentation, and interface follow a logical order, but inconsistent formatting weakens organization. Nesting: Minimal nesting makes the code easy to understand. Clarity of intent: LongAddable and its increment, add, and sum methods clearly express their purpose, supported by documentation. Code length: Appropriately concise for a small interface, with no unnecessary implementation detail. Action granularity: Two method declarations share a line, and the import shares a line with the documentation opening, reducing scanability. Reading flow: The overall sequence is natural, but placing the closing brace beside sum() and compressing declarations interrupts the visual flow.

Run 2

Code Structure: The package, import, annotation, and interface are logically ordered, but compressed formatting weakens separation. Nesting: Minimal nesting makes the code easy to follow. Clarity of intent: The interface name, documentation, and method names clearly communicate concurrent accumulation, although the parameter name x is generic. Code length: Appropriately concise for a small interface. Action granularity: Placing increment() and add(long x) on the same line reduces readability; the import and documentation opener also share a line. Reading flow: The overall sequence is natural, but the closing brace beside sum() and inconsistent line breaks make scanning less smooth.

Run 3

Code Structure: The package, import, documentation, annotation, and interface follow a logical order, but cramped formatting weakens separation. Nesting: Minimal nesting makes the interface easy to scan. Clarity of intent: The documentation and method names clearly describe a concurrent long accumulator, though the parameter name x is generic. Code length: Appropriately concise, with no unnecessary implementation or boilerplate. Action granularity: Two method declarations share one line, and the import shares a line with the documentation opener, reducing readability. Reading flow: Generally natural, but placing the closing brace beside sum() and combining unrelated elements interrupts visual flow.