Sample
int-edc57dc60d49-I01
Remove line comments, block comments, and Javadoc
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 1 | 0–1; higher is more readable |
| Scalabrino | 0.556 | 0–1; higher is more readable |
| Dorn | 0.487 | 0–1; higher is more readable |
| Mi | 0.764 | 0–1; higher is more readable |
| LLOC | 1 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15.67 | 0–20; mean of three runs |
| BTTF | 0.612 | 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. | 51 | +20.4 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 382.574 | −12.625 |
| 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.018 | −7.527 |
Intercept 8.87 + feature contributions = 9.118 (log-odds).
Score = sigmoid(9.118) = 1.
| Score | 0.556 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 51 | +1.027 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 52 | −0.805 |
| 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. | 95.981 | −0.4 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 50.845 | +0.301 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.08 | +0.162 |
Intercept 0.07 + feature contributions = -0.052 (log-odds).
Score = sigmoid(-0.052) = 0.487.
| Score | 0.764 |
|---|
| Score | 1 |
|---|
Run 1
The code is highly readable. It is a small, well-structured interface with a single, clearly named method. The package and imports are appropriately placed. Nesting is absent, and the single method declaration has a clear purpose: setting a type value on a PreparedStatement. The code length is minimal and concise, with no unnecessary logic or duplication. Each action—declaring the constant, defining the method signature, and throwing the exception—is logically separated. The reading flow is natural, moving from package declaration to imports, then to the interface and its member. The only minor flaw is the presence of many blank lines before and within the interface, which slightly disrupts visual flow, but this does not significantly impact overall clarity.
Run 2
The code is a simple, well-structured Java interface with a single method and a constant. It has minimal nesting and clear intent — defining a contract for setting SQL type values. The code is concise and has one action per line. However, the excessive blank lines (dozens of empty lines between elements) disrupt the reading flow and make the file appear longer than necessary, which slightly lowers readability.
Run 3
The code is a cleanly structured Java interface with clear intent, minimal nesting, and concise length. It defines a single method with a well-named signature and a constant, using standard Spring conventions. The action granularity is appropriate, and the reading flow is natural. Minor deductions are for the excessive blank lines, which slightly disrupt visual compactness, and the lack of Javadoc, which would improve clarity of purpose.
Run 1
Code Structure: The interface is logically organized, with imports, a constant, and a method declaration. Nesting: There is no unnecessary nesting. Clarity of intent: Names and parameter types convey SQL parameter handling, though the method's contract and TYPE_UNKNOWN behavior are undocumented. Code length: The substantive code is concise, but excessive blank lines needlessly expand it. Action granularity: Each declaration is separate, and the wrapped throws clause remains readable. Reading flow: Declaration order is natural, but large whitespace gaps interrupt scanning.
Run 2
Code Structure: The package, imports, constant, and method declaration are logically organized within a simple interface. Nesting: There is no nested logic, making the code easy to scan. Clarity of intent: SqlTypeValue and setTypeValue suggest SQL parameter handling, but the contract and TYPE_UNKNOWN lack explanatory documentation, and ps is abbreviated. Code length: The substantive code is concise, but excessive blank lines unnecessarily inflate its visual length. Action granularity: Each import and declaration is separate; the wrapped method signature remains readable. Reading flow: The declaration order is natural, but large whitespace gaps disrupt continuity.
Run 3
Code Structure: A logically organized interface containing one constant and one method, but excessive blank lines obscure its compact structure. Nesting: No nested logic, making it easy to scan. Clarity of intent: SqlTypeValue, TYPE_UNKNOWN, and setTypeValue convey the purpose reasonably well, though ps is abbreviated and the method contract is undocumented. Code length: Actual code is concise, but unnecessary whitespace greatly inflates its visual length. Action granularity: Each declaration occupies its own logical statement; the wrapped method signature remains readable. Reading flow: Package, imports, and declarations follow a natural order, but large empty gaps interrupt the flow.