Sample
int-fe1368901474-I03
Replace method, parameter, and local names with length-matched, meaningful but unrelated names
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.697 | 0–1; higher is more readable |
| Dorn | 0.175 | 0–1; higher is more readable |
| Mi | 0.291 | 0–1; higher is more readable |
| LLOC | 29 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 5.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.56 | 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. | 5686.82 | −187.665 |
| Source linesThe number of non-empty source lines. | 178 | +71.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.657 | −6.986 |
Intercept 8.87 + feature contributions = -114.581 (log-odds).
Score = sigmoid(-114.581) = 0.
| Score | 0.697 |
|---|
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. | 178 | −5.266 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 139 | +4.071 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 139 | −2.769 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 177.974 | +2.078 |
| 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. | 115.983 | −1.247 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 113.402 | +1.025 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.047 | +0.487 |
Intercept 0.07 + feature contributions = -1.552 (log-odds).
Score = sigmoid(-1.552) = 0.175.
| Score | 0.291 |
|---|
| Score | 29 |
|---|
Run 1
The code is highly unreadable due to several critical issues. Variable names are nonsensical (e.g., 'customer', 'currentRecord', 'backupSession', 'nextData', 'pendingBalance') bearing no relation to their actual purpose (thread count, executor, selector provider, etc.). The class has many overloaded constructors with duplicated logic and inconsistent Javadoc coverage, some documenting parameters that do not exist. The method names 'parseValue' and 'validateSession' do not match their documented behaviors (a no-op and selector rebuild, respectively). Import statements are piled without grouping. While indentation and line breaks are syntactically correct, the identifiers, misaligned comments, and tangled constructor delegation make the intent opaque and maintainability poor.
Run 2
The code is highly unreadable due to pervasive, meaningless parameter names (e.g., 'nextItem', 'context', 'primaryMessage', 'defaultBalance') that obscure intent. While the class structure is logical, the constructor overloading creates a tangled web of delegation. Nesting is mostly flat, but clarity of intent is severely compromised. Action granularity is acceptable, but the reading flow is disorganized by the nonsensical names. The 'parseKey' method has poor granularity and unclear intent. Overall, the code appears deliberately obfuscated.
Run 3
The code structure is logical with clear package/import organization, but readability is severely undermined by nonsensical parameter names like 'customer', 'currentRecord', 'backupSession', 'nextData', 'nextNode', 'nextPath', 'shipment', 'defaultAddress', etc. These names appear to be auto-generated or obfuscated, completely obscuring intent. While nesting is flat and action granularity is reasonable, the inconsistent naming pattern makes the numerous overloaded constructors extremely difficult to follow. The Javadoc is helpful but the parameter names don't match the documented purposes (e.g., 'document' instead of 'nThreads'). The final constructor with extensive parameters is inherently complex, but readable parameter names would have helped. The overall structure follows a logical pattern of constructor chaining, but the obfuscated naming defeats the purpose of self-documenting code and makes maintenance extremely error-prone.
Run 1
1. Code Structure: Constructors are grouped logically, followed by operational methods, but numerous overloads create repetition. 2. Nesting: Very shallow; only a simple loop and independent conditionals, making control flow easy to follow. 3. Clarity of intent: Strongly weakened by misleading names such as customer, shipment, parseValue, and validateSession. Types and comments help, but Javadoc parameter names do not match the actual signatures, and the no-op log references a differently named method. 4. Code length: Individual methods are concise, although repetitive constructor forwarding and documentation make the class lengthy. 5. Action granularity: Generally one statement per line, with clear separation of assignments, checks, and delegation. 6. Reading flow: Constructor chaining and consistent method layout provide reasonable flow, but inconsistent indentation, arbitrary naming, and positional Object varargs require readers to repeatedly infer parameter roles.
Run 2
Code Structure: Constructors are grouped logically, delegate consistently, and precede operational methods. Nesting: Very shallow; only a simple loop and independent conditionals. Clarity of intent: Severely weakened by arbitrary parameter and method names such as customer, secureBalance, parseValue, and parseKey. Types and comments help, but Javadoc parameter names do not match the actual signature, and the no-op log references a differently named method. Code length: Individual methods are concise, although numerous overloads and repetitive documentation make the class lengthy. Action granularity: Generally one statement per line, with constructor delegation and factory calls remaining manageable. Reading flow: Predictable class organization and consistent delegation support navigation, but inconsistent naming and some uneven indentation interrupt comprehension. Overall, clean structural mechanics are offset by misleading identifiers and documentation.
Run 3
Code Structure: Constructors are grouped logically, followed by operational methods, and delegation avoids duplicated implementation. Nesting: Shallow loops and independent conditionals make control flow easy to follow. Clarity of intent: Misleading names such as customer, shipment, parseValue, and validateSession obscure thread counts and event-loop operations. Javadoc parameter names do not match signatures, and the no-op log references a different method name. Code length: Individual bodies are concise, but numerous similar constructor overloads and repetitive documentation increase reading effort. Action granularity: Statements generally perform one action per line, although factory calls embedded in superclass arguments require some unpacking. Reading flow: Consistent delegation and mostly conventional formatting help, but inconsistent naming across overloads, long parameter lists, and positional Object varargs force readers to infer meaning from types and implementation.