Sample
int-414fa9d7b380-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.346 | 0–1; higher is more readable |
| Scalabrino | 0.88 | 0–1; higher is more readable |
| Dorn | 0.386 | 0–1; higher is more readable |
| Mi | 0.687 | 0–1; higher is more readable |
| LLOC | 30 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.355 | 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. | 1638 | −54.054 |
| Source linesThe number of non-empty source lines. | 130 | +52 |
| 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.969 | −7.453 |
Intercept 8.87 + feature contributions = -0.637 (log-odds).
Score = sigmoid(-0.637) = 0.346.
| Score | 0.88 |
|---|
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. | 126 | −3.425 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 76 | +1.892 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 129.837 | +1.405 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 76 | −1.323 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 96.969 | +0.76 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.035 | +0.599 |
| 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. | 96.969 | −0.442 |
Intercept 0.07 + feature contributions = -0.464 (log-odds).
Score = sigmoid(-0.464) = 0.386.
| Score | 0.687 |
|---|
| Score | 30 |
|---|
Run 1
The code is highly readable with clear structure, minimal nesting, and good Javadoc. One minor issue: an unexplained, nonsensical integer assignment line in getDependencyCheck(), likely an obfuscation artifact, which disrupts clarity.
Run 2
The code is generally well-structured with clear field declarations and standard getters/setters, but contains a critical readability issue: an obfuscated, meaningless line inside getDependencyCheck() that performs fake bitwise operations and assigns to an unused variable. This breaks reading flow and clarity of intent. The class is otherwise flat, uses concise one-action-per-line methods, and has good Javadocs, but the inserted noise severely hurts readability and suggests tampering or obscured logic. Naming is clear, and length is appropriate for a defaults holder, but the odd code renders the method ambiguous and untrustworthy.
Run 3
The code is generally very readable: it has a clear, logical class structure with well-named fields and accessor methods, flat nesting, concise but descriptive Javadoc, and good action granularity. However, there is one severe flaw: an obfuscated line of dead code in getDependencyCheck() that breaks the reading flow and clarity. The code's overall clarity, structure, and conciseness are excellent, but this single line of nonsense code significantly impairs readability and maintainability.
Run 1
Code Structure: Fields and paired accessors are logically organized, but getDependencyCheck contains an unrelated computation block. Nesting: Methods are flat except for that unnecessary local block. Clarity of intent: Descriptive names, nullability annotations, constants, and Javadoc clearly communicate the holder's purpose; the cryptically named temporary variable and bitwise operations obscure intent locally. Code length: Accessors are concise and documentation is useful, though the redundant computation adds needless code. Action granularity: Most lines perform one action, but the injected block compresses three statements onto one line. Reading flow: Consistent accessor ordering and formatting make the class easy to scan, interrupted noticeably by the unindented, unexplained block.
Run 2
Code Structure: Fields and paired accessors are logically organized, but getDependencyCheck contains an unrelated no-op block. Nesting: Almost entirely flat, with only one unnecessary nested scope. Clarity of intent: Descriptive names, explicit defaults, nullability annotations, and Javadoc make the holder's purpose clear; the cryptic variable and meaningless bit operations obscure one method. Code length: Accessors are concise, although documentation is extensive and the injected block adds needless code. Action granularity: Most lines perform one action, but the no-op block compresses a declaration and multiple operations onto one line. Reading flow: Consistent accessor ordering and formatting support natural reading, interrupted by the unindented, obfuscated block.
Run 3
Code Structure: Fields and paired accessors are logically organized, but getDependencyCheck contains an unrelated no-op block. Nesting: Methods are flat apart from that unnecessary extra scope. Clarity of intent: Descriptive names, nullable annotations, constants, and Javadoc clearly explain the defaults; the cryptic variable and bitwise operations obscure intent locally. Code length: Accessors are concise, though documentation is extensive and the no-op code adds needless length. Action granularity: Most lines perform one action, but the injected block compresses several statements onto one line. Reading flow: Consistent formatting and predictable accessor ordering support natural reading, while the unindented, dense block abruptly interrupts it.