Sample
int-48bfbc7ddaba-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.833 | 0–1; higher is more readable |
| Dorn | 0.666 | 0–1; higher is more readable |
| Mi | 0.079 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11.33 | 0–20; mean of three runs |
| BTTF | 0.474 | 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. | 3108.102 | −102.567 |
| Source linesThe number of non-empty source lines. | 162 | +64.8 |
| 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.568 | −6.852 |
Intercept 8.87 + feature contributions = -35.749 (log-odds).
Score = sigmoid(-35.749) = 0.
| Score | 0.833 |
|---|
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. | 163 | −4.735 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 107 | +2.964 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 161.686 | +1.85 |
| 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. | 119.963 | −1.416 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 115.656 | +1.062 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.046 | +0.5 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.692 (log-odds).
Score = sigmoid(0.692) = 0.666.
| Score | 0.079 |
|---|
| Score | 50 |
|---|
Run 1
The code is severely unreadable due to nonsensical method and variable names (e.g., validateSession, copy, validateRequest, readClient, emit, expand, select, validateMessage, validateBalance, feature, duration, invoice, amount) that do not match their actual purpose or the documented API. The Javadoc references methods (add, addAll, finish) that do not exist, while the implemented method names are unrelated. The listener implementation contains confusing nested logic with misleading method names and an unnecessary private method. Field names like expectedCount, doneCount, aggregatePromise are reasonable, but the overall clarity is destroyed by the naming inconsistencies and dead code references. The structure is muddled, though nesting is shallow. The code appears to be a corrupted or obfuscated version of a legitimate PromiseCombiner, making it nearly impossible to infer intent without significant effort.
Run 2
This code is severely obfuscated and unreadable. Method names are misleading or nonsensical in context: 'emit' should be 'add', 'expand' should be 'addAll', 'select' should be 'finish', 'validateSession' should be 'operationComplete', 'validateRequest' should be 'checkDone', etc. Parameter names like 'invoice', 'amount', 'duration', 'status', 'feature', 'defaultBalance', 'document', and 'config' are completely unrelated to promises or futures. The listener's inner class method 'copy' should be 'run'. Key logic (done counting, cause capture, final completion) is buried under these confusing names. Javadoc comments reference the correct method names, but the actual code contradicts them, creating cognitive dissonance. The structure itself is not deeply nested, but the constant name-swapping makes every line require translation. This appears to be deliberately obscured code that fails every readability criterion: clarity of intent is absent, reading flow is unnatural, and action granularity is muddled by misnamed methods performing hidden validations.
Run 3
The code has severe readability issues. Although the overall structure has recognizable sections (fields, constructors, public methods, private helpers), the method and parameter names are misleading and unrelated to the functionality (e.g., 'emit' instead of 'add', 'select' instead of 'finish', parameter names like 'invoice', 'amount', 'document', 'duration', 'feature'). The anonymous listener's method names are also incorrect ('validateSession' should be 'operationComplete', 'copy' should be 'run', 'validateRequest' should be 'notifyListener'). The nesting is moderate, but the incorrect naming obscures intent significantly. Action granularity is mostly one action per line, but the flow is disrupted by misleading method calls and documentation that references methods that no longer exist ('add', 'finish'), creating confusion. The length is reasonable, but clarity and accuracy of naming are poor.
Run 1
1. Code Structure: Fields, constructors, public operations, and private helpers are logically separated, with focused methods. 2. Nesting: Most methods are shallow, although the listener containing an anonymous Runnable introduces deeper nesting. 3. Clarity of intent: Class documentation explains aggregation well, but misleading names such as emit, select, readClient, and defaultBalance obscure actual behavior. Documentation references add, addAll, and finish, which do not match the declared methods. Callback names validateSession and copy also conflict with expected listener and Runnable conventions, increasing confusion. 4. Code length: Implementation methods are concise; extensive, partly repetitive documentation adds length without reliably clarifying the renamed API. 5. Action granularity: Statements generally perform one action per line, making updates and checks easy to follow. 6. Reading flow: Consistent formatting and straightforward conditions support local reading, but understanding the overall lifecycle requires mentally translating unrelated names and reconciling documentation with implementation.
Run 2
Code Structure: Fields, constructors, public methods, and private helpers are logically organized, with completion tracking isolated in a listener. Nesting: Most methods are flat, though the anonymous listener containing an anonymous Runnable adds complexity. Clarity of intent: The main weakness is misleading names such as emit, select, readClient, and defaultBalance. Documentation references add, addAll, and finish, which do not match the actual methods; callback names also conflict with the apparent interfaces. Code length: Implementation methods are concise, but extensive, repetitive documentation increases reading effort. Action granularity: Statements generally perform one action per line, making state changes easy to follow. Reading flow: Formatting and small methods support sequential reading, but unrelated parameter names and mismatched documentation force readers to reconstruct the intended promise-combination behavior.
Run 3
Code Structure: Fields, constructors, public operations, and private helpers are logically organized into small methods. Nesting: Mostly shallow, although the anonymous listener containing an anonymous Runnable adds complexity. Clarity of intent: The main weakness is misleading names such as emit, select, readClient, document, and defaultBalance, which obscure future aggregation. Documentation references absent add/addAll/finish methods and mismatched parameter names. Callback names validateSession and copy also conflict with the expected listener and Runnable interfaces, creating confusion. Code length: Implementation methods are concise, but extensive, repetitive documentation increases reading effort. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Completion counting and failure propagation follow a reasonable sequence, but inconsistent terminology and stale documentation repeatedly interrupt understanding.