Sample
int-fc4e9e2ceffd-I01
Remove line comments, block comments, and Javadoc
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.473 | 0–1; higher is more readable |
| Dorn | 0.063 | 0–1; higher is more readable |
| Mi | 0.499 | 0–1; higher is more readable |
| LLOC | 36 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.395 | 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. | 4989.917 | −164.667 |
| Source linesThe number of non-empty source lines. | 109 | +43.6 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 5.074 | −7.611 |
Intercept 8.87 + feature contributions = -119.808 (log-odds).
Score = sigmoid(-119.808) = 0.
| Score | 0.473 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 109 | +3.033 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 110 | −2.858 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 109 | −2.08 |
| 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. | 113.936 | −1.161 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 108.93 | +1.113 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.098 | −0.013 |
Intercept 0.07 + feature contributions = -2.701 (log-odds).
Score = sigmoid(-2.701) = 0.063.
| Score | 0.499 |
|---|
| Score | 36 |
|---|
Run 1
The code is well-structured with clear separation of concerns: public entry point, internal handler, helper method, and abstract methods. It uses a flat if-else chain rather than nested conditionals, making the session state handling easy to follow. Each branch performs one logical action with clear intent. Method names are descriptive (handleRequestInternal, writeFrame, getCallbackParam). Logging is consistently guarded. The only minor readability drawbacks are some unnecessary blank lines around annotations and slightly verbose logging blocks that could be extracted, but overall the code maintains good action granularity and natural reading flow.
Run 2
The code is well-structured with clear separation of concerns: public entry point, template method pattern, and helper methods. Nesting is flat — only one level of conditional branching. Variable names clearly express intent (e.g., 'sockJsSession', 'formattedFrame'). Each branch in handleRequestInternal performs a single logical action. However, the callback param extraction chains several operations in one line, reducing action granularity. Comments are sparse but meaningful. Overall, the class reads naturally from top to bottom.
Run 3
The code is well-structured and clearly organized into logical methods with distinct responsibilities. The class has a single clear purpose and uses concise method names that convey intent. Nesting is minimal—mostly single-level conditionals—which aids readability. Each method performs focused actions, though some lines combine multiple operations (e.g., 'writeFrame' combines formatting, writing, and exception handling). The reading flow is natural: request handling progresses logically through session states. Some minor issues slightly reduce readability: the empty/commented whitespace after the class declaration looks like leftover artifacts, a few lines are long (e.g., getFrameFormat calls), and the 'getCallbackParam' method packs multiple steps into one expression-heavy block. Overall, this is maintainable, idiomatic Spring code with clear naming and structure.
Run 1
Code Structure: Well-organized methods separate request handling, frame writing, and callback parsing. Nesting: Shallow overall; logging checks add only one nested level within the session-state branches. Clarity of intent: Descriptive method and variable names make transport behavior clear, though the callback key "c" and validation pattern lack explanation. Code length: Implementation is reasonably concise, but excessive blank lines and repeated logging guards add visual bulk. Action granularity: Most lines perform one clear action; the chained query-parsing expression is slightly dense. Reading flow: Request handling follows a natural progression through session states, with supporting helpers below. Inconsistent whitespace interrupts an otherwise straightforward reading experience.
Run 2
Code Structure: Methods logically separate request handling, frame writing, and callback parsing, with clear extension points. Nesting: The session-state branch chain is straightforward; nested logging checks add only modest depth. Clarity of intent: Descriptive method and variable names make the transport behavior understandable, although the callback key "c" and validation pattern lack explanation. Code length: Implementation is reasonably concise, but excessive blank lines and repeated logging guards add visual clutter. Action granularity: Most statements perform one action; the query-parsing chain combines several operations while remaining readable. Reading flow: The entry point leads naturally into internal handling and helpers, and state transitions are easy to follow. Inconsistent whitespace and long signatures slightly interrupt scanning.
Run 3
Code Structure: Well-organized class with separate methods for request handling, frame writing, and callback extraction. Nesting: Shallow overall; logging checks add only one level within straightforward state branches. Clarity of intent: Descriptive method and variable names make session lifecycle handling clear, although the callback key "c" and validation pattern lack explanatory context. Code length: Methods are concise, but excessive blank lines and repeated logging guards introduce visual clutter. Action granularity: Most statements perform one action; the chained query-parameter extraction compresses several operations into one line. Reading flow: Request setup naturally leads to state dispatch and helper methods, with consistent formatting apart from unnecessary whitespace. Overall, readable and maintainable with minor presentation and contextual-documentation weaknesses.