Sample

int-075cc4801f4f-I01

Remove line comments, block comments, and Javadoc

Matched original source

Lines16

Scores

MethodScoreScale
Posnett0.9020–1; higher is more readable
Scalabrino0.9670–1; higher is more readable
Dorn0.7290–1; higher is more readable
Mi0.6260–1; higher is more readable
LLOC3Logical lines; fewer is more readable
DeepSeek V4 Pro17.670–20; mean of three runs
GPT-6.1 Sol190–20; mean of three runs
BTTF0.6360–1; higher is more readable

Views

Source code

package com.google.common.cache; import com.google.common.annotations.GwtCompatible; @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.578−6.867
Source linesThe number of non-empty source lines.16+6.4
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

Intercept 8.87 + feature contributions = 2.222 (log-odds).
Score = sigmoid(2.222) = 0.902.

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.50.882+1.51
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.0−0.804
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.17+0.434
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.122−0.244
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.15.769−0.189
Indentation frequencyHow rapidly indentation changes from line to line.16−0.184

Intercept 0.07 + feature contributions = 0.991 (log-odds).
Score = sigmoid(0.991) = 0.729.

Score0.626
Score3
Run 1

The code is highly readable, with a clear interface definition and logical structure. The package and import statements are standard and concise. Nesting is non-existent, and the intent—defining a contract for long-addable operations—is evident from the method names and annotations. Action granularity is appropriate, with one method per line and proper spacing. The only minor deductions are due to excessive blank lines between the import and annotation, and the lack of Javadoc comments explaining the interface's purpose, which slightly affects clarity for new readers.

Run 2

The code is highly readable. It defines a small, focused interface with a clear purpose (adding long values). The structure is logical and flat: a package declaration, a single import, an annotation, and three method signatures. There is no nesting or complex logic, and naming is consistent and intent-revealing (`increment`, `add`, `sum`). The code is concise and each method declaration is on its own line, contributing to good action granularity. Reading flow is natural from package to interface to methods. Minor deductions: multiple blank lines after the import slightly disrupt flow, and Javadoc is absent, though the method names are self-explanatory.

Run 3

The code is highly readable. It is a concise interface definition with a clear purpose: providing a long-addable abstraction. The structure is logical, with package and import statements at the top, followed by the annotation and interface. Nesting is minimal and flow is straightforward. Each method declaration is on its own line, maintaining good action granularity. Clarity of intent is strong, with clear method names like increment, add, and sum. The only minor issue is the excessive blank lines between the package and import, which slightly disrupts the reading flow. Otherwise, the code is exemplary in readability.

Run 1

Code Structure: The package, import, annotation, and interface are logically organized. Nesting: There is only one shallow interface scope. Clarity of intent: LongAddable and its increment, add, and sum methods clearly describe a numeric accumulation contract, although the parameter name x is less descriptive than delta. Code length: The interface is concise, with no unnecessary implementation or declarations. Action granularity: Each method declaration occupies its own line. Reading flow: The methods are naturally ordered and separated, but excessive blank lines between the import and annotation slightly disrupt the otherwise clean presentation.

Run 2

Code Structure: A logically organized, minimal interface with an appropriate package, import, and annotation. Nesting: No nested control flow; only the necessary interface scope. Clarity of intent: LongAddable and its increment, add, and sum methods clearly convey a mutable numeric accumulator, although x is a generic parameter name and behavioral contracts are undocumented. Code length: Very concise, with no unnecessary implementation, but excessive blank lines before the annotation add visual clutter. Action granularity: Each method declaration occupies its own line. Reading flow: The conventional package-to-import-to-interface order and spacing between methods make the code easy to scan.

Run 3

Code Structure: A logically organized interface with three related methods. Nesting: Flat, with no nested control flow. Clarity of intent: The interface and method names clearly communicate an additive counter, though the parameter name x is generic. Code length: Minimal and appropriate, with only excess blank lines adding clutter. Action granularity: Each method declaration occupies its own line. Reading flow: Natural progression from package and import to annotation and interface; excessive whitespace before the annotation slightly disrupts the flow.