Sample
int-f2968757e734-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.642 | 0–1; higher is more readable |
| Dorn | 0.178 | 0–1; higher is more readable |
| Mi | 0.097 | 0–1; higher is more readable |
| LLOC | 49 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.239 | 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. | 5185.604 | −171.125 |
| Source linesThe number of non-empty source lines. | 118 | +47.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.848 | −7.273 |
Intercept 8.87 + feature contributions = -122.328 (log-odds).
Score = sigmoid(-122.328) = 0.
| Score | 0.642 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 119 | −3.177 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 105 | +2.895 |
| 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. | 134.975 | −2.052 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 105 | −1.989 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 133.824 | +1.355 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 117.912 | +1.238 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.084 | +0.129 |
Intercept 0.07 + feature contributions = -1.53 (log-odds).
Score = sigmoid(-1.53) = 0.178.
| Score | 0.097 |
|---|
| Score | 49 |
|---|
Run 1
The overall structure is logical with clear separation of concerns through an abstract NumberConverter class. However, readability is severely compromised by the presence of obfuscated, dead code in the fromConnectHeader method, which contains an unexplained loop and meaningless variable names (lI0O_41d517a4, lI0O_8718f354). This creates confusion and violates clarity of intent. The class has moderate nesting, acceptable method lengths, and mostly good action granularity, but the obfuscated block disrupts reading flow. Some methods like configure have minor issues (empty line before closing brace, redundant empty line), and the cast method uses an unchecked cast without inline documentation. The use of assert for parameter validation is weak. Without the obfuscated code, this would score higher (around 15-16), but the dead code and poor variable names significantly reduce readability.
Run 2
The code is generally structured but has a serious readability flaw: dead/junk code ({int lI0O_41d517a4=0x6BE3;...}) in fromConnectHeader is confusing and unrelated to logic. The class has clear purpose and moderate nesting, but it contains multiple concerns (converter, header converter, serializer/deserializer). There are minor style issues: unused imports (Map is used, but java.util.HashMap is used; okay), blank lines and one-line methods reduce flow. Method length is acceptable; error handling is clear. However, the assert statements are not appropriate for public APIs and reduce clarity. Also, methods like configure and cast are simple but slightly scattered. Overall, logic is understandable, but the injected nonsense block and mixed responsibilities lower readability significantly.
Run 3
The code has a clear structure and purpose, with logical class organization and mostly flat, readable methods. Javadoc and method parameter documentation are helpful. However, several issues reduce readability: a mysterious dead-code do-while loop appears inside a method body, which is confusing and should be removed. The configure method contains an empty line inside the method, slightly disrupting flow. Action granularity is mostly one action per line, but some expressions are dense. The cast method uses an unchecked cast and lacks explanatory comments. Error handling wraps exceptions clearly, though repeated try-catch blocks add length. Overall, the code is understandable but includes an anomalous artifact that significantly harms clarity.
Run 1
Code Structure: Well-organized fields, constructor, configuration, conversion, and cleanup methods, but an unrelated block disrupts fromConnectHeader. Nesting: Generally shallow, with straightforward try/catch handling; the inserted block adds unnecessary scope and a do/while loop. Clarity of intent: Descriptive names, documentation, and delegation make the converter's purpose clear, except for the opaque identifiers and meaningless operations in that block. Code length: Mostly concise, though the unrelated loop adds needless code. Action granularity: Most statements occupy separate lines, but the inserted block compresses declarations, assignments, and control flow into one line. Reading flow: Method boundaries and consistent patterns support natural reading; minor spacing inconsistencies and the abrupt obfuscated block interrupt it.
Run 2
Code Structure: The class is logically organized into initialization, configuration, conversion, and cleanup methods, but an unrelated block disrupts fromConnectHeader. Nesting: Most methods are flat, with simple try/catch handling; the inserted block adds unnecessary scope and loop nesting. Clarity of intent: Descriptive method names, fields, and documentation clearly communicate numeric conversion, while opaque variable names and hexadecimal operations obscure the inserted block's purpose. Code length: Generally concise, with sensible delegation between header and data conversion methods; the extraneous loop adds needless code. Action granularity: Almost all statements perform one action per line, but the inserted block compresses declarations, assignments, and a loop onto one line. Reading flow: Consistent method patterns support natural reading, though minor spacing inconsistencies and the unindented, obfuscated block noticeably interrupt it.
Run 3
Code Structure: Well-organized fields, constructor, configuration, conversion, and cleanup methods, but an unrelated block disrupts fromConnectHeader. Nesting: Generally shallow; the injected block adds unnecessary scope and a do-while loop. Clarity of intent: Descriptive names, documentation, and explicit exception handling make the converter's purpose clear, while opaque variable names and hexadecimal operations obscure the injected block's intent. Code length: Mostly concise, with sensible delegation between header and data conversion methods; the extra block is unnecessary. Action granularity: Most statements occupy separate lines, but the injected block compresses declarations, assignments, and loop control onto one line. Reading flow: Methods follow a natural progression, though inconsistent spacing and the abrupt, unformatted block interrupt readability.