Sample
int-a2617cb50afd-I01
Remove line comments, block comments, and Javadoc
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.986 | 0–1; higher is more readable |
| Scalabrino | 0.825 | 0–1; higher is more readable |
| Dorn | 0.531 | 0–1; higher is more readable |
| Mi | 0.756 | 0–1; higher is more readable |
| LLOC | 5 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18.33 | 0–20; mean of three runs |
| BTTF | 0.373 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 36 | +14.4 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 368.017 | −12.145 |
| 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.582 | −6.873 |
Intercept 8.87 + feature contributions = 4.253 (log-odds).
Score = sigmoid(4.253) = 0.986.
| Score | 0.825 |
|---|
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. | 70.973 | +0.659 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 36 | +0.508 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 36 | −0.405 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.083 | +0.138 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 33 | −0.132 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 35.708 | +0.089 |
Intercept 0.07 + feature contributions = 0.123 (log-odds).
Score = sigmoid(0.123) = 0.531.
| Score | 0.756 |
|---|
| Score | 5 |
|---|
Run 1
The code is highly readable. It has a clear structure: a single class extending CodecException with a serialVersionUID and four constructors. Nesting is minimal and flat. Intent is obvious—it's a custom exception for encoder errors. The code is concise, with no unnecessary complexity. Action granularity is appropriate, with each constructor on its own line. Reading flow is natural, following standard Java exception patterns. Minor deductions for extra whitespace between constructors, which slightly disrupts flow but doesn't impact clarity.
Run 2
The code is highly readable due to its simple, conventional structure. It is a standard exception class extending CodecException with four standard constructors, each delegating to the superclass. The class is flat with no nesting, and each action is concise and clear. Intent is unambiguous: to provide a custom exception for encoder errors. The code length is minimal and appropriate, with no unnecessary methods or fields. The only minor readability issue is the presence of multiple blank lines between constructors, which creates visual gaps that slightly disrupt the natural reading flow. Removing extra blank lines would result in a perfect score.
Run 3
The code is highly readable: it follows a clear package and class structure, uses minimal nesting, and has obvious intent as a simple exception class. Constructors are concise and delegate cleanly to the parent class. The only minor issue is the unnecessary blank lines between constructors, which slightly disrupts reading flow.
Run 1
Code Structure: A straightforward exception subclass with consistently organized constructors. Nesting: Minimal, with no nested control flow. Clarity of intent: The class name, superclass, and constructor parameters clearly communicate its purpose. Code length: Concise implementation, though excessive blank lines add unnecessary visual length. Action granularity: Each constructor performs at most one action, clearly separated onto its own line. Reading flow: Natural and predictable; redundant whitespace slightly interrupts otherwise smooth scanning.
Run 2
Code Structure: The exception class is logically organized, with a serialization identifier followed by standard constructors. Nesting: Minimal, limited to the class and constructor bodies. Clarity of intent: The class name, inheritance, and constructor parameters clearly convey an encoder-specific exception that delegates to CodecException. Code length: The implementation is concise, though excessive blank lines unnecessarily lengthen its presentation. Action granularity: Each nonempty constructor contains a single superclass call on its own line. Reading flow: The consistent constructor layout is easy to follow, but repeated empty lines interrupt the visual flow.
Run 3
Code Structure: A straightforward exception subclass with a serialization identifier followed by constructors. Nesting: Minimal, with no control-flow nesting. Clarity of intent: The class name, inheritance, and constructor parameters clearly communicate its purpose. Code length: Concise implementation, though excessive blank lines unnecessarily expand the visual footprint. Action granularity: Each constructor performs at most one clear action per line. Reading flow: Constructor overloads are easy to scan, but inconsistent, excessive spacing interrupts an otherwise natural flow.