Sample
int-81e03ae9a774-I01
Remove line comments, block comments, and Javadoc
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.003 | 0–1; higher is more readable |
| Scalabrino | 0.717 | 0–1; higher is more readable |
| Dorn | 0.612 | 0–1; higher is more readable |
| Mi | 0.243 | 0–1; higher is more readable |
| LLOC | 8 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.767 | 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. | 629.447 | −20.772 |
| Source linesThe number of non-empty source lines. | 33 | +13.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.724 | −7.085 |
Intercept 8.87 + feature contributions = -5.787 (log-odds).
Score = sigmoid(-5.787) = 0.003.
| Score | 0.717 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| 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. | 75.971 | +0.447 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 33 | +0.404 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 34 | −0.167 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.091 | +0.06 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 32.818 | +0.049 |
Intercept 0.07 + feature contributions = 0.457 (log-odds).
Score = sigmoid(0.457) = 0.612.
| Score | 0.243 |
|---|
| Score | 8 |
|---|
Run 1
The code is highly readable. It follows a clear, logical structure with package and imports at the top, followed by a single class with a constructor, accessor method, and overridden encode method. Nesting is minimal, and the class has a clear, single responsibility. The constructor uses ObjectUtil.checkNotNull for input validation, making intent explicit. The encodeAsByteBuf method is concise, with one action per line, and the flow naturally follows the SOCKS protocol structure. Minor deductions are for unused blank lines and a lack of Javadoc, but overall readability is excellent.
Run 2
The code is well-structured with clear separation of concerns, minimal nesting, and concise implementation. The class has a single responsibility and follows the builder pattern effectively. Intent is clear: a response object carrying an authentication scheme. Lines are short and each performs one action. Minor deductions: unnecessary import whitespace and a blank method section before authScheme() slightly disrupt reading flow, though not severely. Overall, highly readable.
Run 3
The code is highly readable with a clean, logical structure. The class has a single, clear responsibility: representing a SOCKS INIT response. Imports are minimal and relevant. The constructor uses ObjectUtil.checkNotNull for validation, making intent explicit. Methods are concise and well-named (authScheme(), encodeAsByteBuf). Nesting is completely flat, with no conditional logic or deep indentation. Action granularity is ideal—one operation per line in the encode method. The only minor deductions are the slightly excessive blank lines within the class body and a missing newline at the end of the file, which slightly disrupt visual flow. Overall, the code follows standard Java conventions and Netty patterns, making it immediately understandable to any developer familiar with the codebase.
Run 1
Code Structure: Logically organized into a field, constructor, accessor, and encoding method. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive class, method, and variable names make the response's purpose clear; constructor validation is explicit. Code length: Implementation is concise, but excessive blank lines add unnecessary visual length. Action granularity: Each statement performs one clear action on its own line. Reading flow: The member order is natural, and encoding steps are easy to follow, though inconsistent whitespace interrupts visual continuity.
Run 2
Code Structure: The class is logically organized into a field, constructor, accessor, and encoding method. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names and straightforward validation make the response's purpose clear. Code length: The implementation is concise, although excessive blank lines add unnecessary visual length. Action granularity: Each statement performs one clear action, and the two encoded values are written on separate lines. Reading flow: The progression from initialization to access and serialization is natural, but inconsistent whitespace interrupts scanning.
Run 3
Code Structure: Logically organized into a field, constructor, accessor, and encoding method. Nesting: Flat and easy to follow, with no nested control flow. Clarity of intent: Descriptive class, field, and method names clearly convey a SOCKS initialization response and its serialization. Code length: The implementation is concise, although excessive blank lines add unnecessary visual length. Action granularity: Each statement performs one clear action. Reading flow: The progression from initialization to access and encoding is natural, but inconsistent whitespace slightly disrupts scanning.