Sample
int-116201ba2008-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.883 | 0–1; higher is more readable |
| Scalabrino | 0.992 | 0–1; higher is more readable |
| Dorn | 0.847 | 0–1; higher is more readable |
| Mi | 0.771 | 0–1; higher is more readable |
| LLOC | 3 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs |
| BTTF | 0.657 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (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.71 | −7.066 |
| 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.023 (log-odds).
Score = sigmoid(2.023) = 0.883.
| Score | 0.992 |
|---|
Feature contributions
| Feature | Value | Contribution (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.941 | +0.872 |
| 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 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 12 | −0.322 |
| 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. | 15.806 | −0.189 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.078 | +0.186 |
Intercept 0.07 + feature contributions = 1.71 (log-odds).
Score = sigmoid(1.71) = 0.847.
| Score | 0.771 |
|---|
| Score | 3 |
|---|
Run 1
This is a very readable interface definition. The structure is straightforward: package declaration, a single import, Javadoc, annotation, and three clear method signatures. There is no nesting or complex logic. The intent is explicit — a type for concurrent long addition — and the method names (inc, add, sum) are concise and self-explanatory. The code is extremely short and has one action per line. The reading flow is natural: documentation first, then annotation, then method declarations in logical order. Minor deductions: the Javadoc could slightly expand on thread-safety guarantees, and the lack of a newline between the package and import is trivial.
Run 2
The code is exceptionally readable. It presents a concise, well-structured interface with a clear purpose: concurrent addition of longs. The package and import statements are properly placed, and the Javadoc comment concisely explains the interface's role. The three methods—inc(), add(long x), and sum()—are intuitively named and logically ordered, conveying their intent without ambiguity. The code is flat with no nesting, and each method declaration is on its own line, enhancing action granularity. Its brevity avoids unnecessary complexity, making the reading flow natural and direct.
Run 3
The code is exceptionally readable. It has a clear, logical structure with a single package declaration, a necessary import, and a well-defined interface. Nesting is non-existent as the code is flat. The intent is unambiguous due to the descriptive interface name 'LongAddable', the concise Javadoc explaining its purpose, and the clear method names ('inc', 'add', 'sum'). Code length is minimal and appropriate, containing no unnecessary elements. Action granularity is perfect, with each method declaration on its own line. The reading flow is natural, starting with package context, moving to documentation, and then presenting the interface contract.
Run 1
Code Structure: A logically organized interface with a package declaration, import, documentation, annotation, and three related methods. Nesting: Minimal, with only the interface body. Clarity of intent: The documentation clearly describes concurrent accumulation, and method names communicate their roles, though inc and x are slightly less descriptive than increment and value. Code length: Concise, with no unnecessary implementation or boilerplate. Action granularity: Each method declaration occupies its own line. Reading flow: Natural top-to-bottom progression, with blank lines separating methods; a blank line between the package and import would slightly improve formatting.
Run 2
Code Structure: The package, import, documentation, annotation, and interface are logically organized. Nesting: A single interface level keeps the code flat and easy to scan. Clarity of intent: Documentation clearly describes the purpose, and add() and sum() are intuitive; inc() and parameter x are slightly less descriptive than increment() and delta. Code length: The interface is concise, with no unnecessary implementation or boilerplate. Action granularity: Each method declaration occupies its own line. Reading flow: Methods are separated by blank lines and follow a natural update-then-query order; a blank line between the package and import would slightly improve formatting.
Run 3
Code Structure: A compact interface cleanly groups three related operations. Nesting: No nested control flow or unnecessary structural complexity. Clarity of intent: The documentation and method signatures clearly convey a concurrent long accumulator, though 'inc' and parameter 'x' are less descriptive than 'increment' and 'value'. Code length: Minimal, with no redundant implementation or commentary. Action granularity: Each method declaration occupies its own line. Reading flow: Package, import, documentation, annotation, and interface appear in a natural order, with blank lines separating methods; a blank line between the package and import would slightly improve readability.