Sample
int-ef306e014695-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.542 | 0–1; higher is more readable |
| Dorn | 0.778 | 0–1; higher is more readable |
| Mi | 0.268 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 4 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10 | 0–20; mean of three runs |
| BTTF | 0.279 | 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. | 4764.319 | −157.223 |
| Source linesThe number of non-empty source lines. | 129 | +51.6 |
| 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.053 | −7.579 |
Intercept 8.87 + feature contributions = -104.332 (log-odds).
Score = sigmoid(-104.332) = 0.
| Score | 0.542 |
|---|
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. | 130 | −3.567 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 116 | +3.275 |
| 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. | 123.985 | −1.586 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 128.848 | +1.391 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 123.985 | +1.196 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.089 | +0.077 |
Intercept 0.07 + feature contributions = 1.254 (log-odds).
Score = sigmoid(1.254) = 0.778.
| Score | 0.268 |
|---|
| Score | 50 |
|---|
Run 1
The code is nearly unreadable due to severely obfuscated naming and misleading method signatures. While the structure follows a standard Spring converter pattern, nearly every identifier has been renamed to nonsensical terms (e.g., 'contain', 'collect', 'findWindow', 'removeRecord', 'createAccount', 'validateAccount', 'sharedKey', 'cachedAccount', 'price', 'limit'), completely obscuring the original intent of converting map entries and handling type conversions. The logic flow is disrupted by these poor names, making it impossible to follow without reverse-engineering the purpose. Nesting is shallow and indentation consistent, and line granularity is okay, but clarity of intent is catastrophically low. The code length is reasonable, but the semantics are lost. Minor naming inconsistencies (e.g., 'readNode' method actually adds to a map) compound confusion. Overall, the code is structurally sound but intentionally or accidentally obfuscated, earning very low readability despite proper formatting.
Run 2
This code is severely obfuscated. The variable names are unrelated to their function (e.g., 'sharedKey' for source map, 'cachedAccount' for list, 'price' for entry, 'findWindow'/'removeRecord' for type conversion), and method names like 'collect', 'contain', 'createAccount', 'validateAccount', and 'readNode' do not reflect actual Map conversion semantics. The core algorithm is buried under misdirection: comments describe straight-forward map copying, but the code uses confusing action flows and misleading names. While the class structure and method decomposition are technically organized, intent is deeply ambiguous, and the logic flow is unnatural. Action granularity is acceptable, but clarity, naming, and semantic coherence are extremely poor, making the code hard to read, maintain, or verify.
Run 3
The code is poorly readable due to obfuscated naming and misleading method names. The class name suggests a Map converter, but method names like validateRequest, contain, collect, createAccount, validateAccount, findWindow, removeRecord, and addToMap/readNode do not convey their actual logic. The code has illogical variable names (e.g., finalToken, sharedNode, buffer, balance, secureKey, price, cachedEvent). The action granularity is mixed, with multiple logical operations packed into some lines. Nesting is not extreme, but the reading flow is disrupted by non-sequential, semantic mismatches. The structure is topically linear but intent is unclear, making the code almost unreadable despite its short length.
Run 1
Code Structure: The converter is logically divided into conversion logic, helpers, and an entry holder. Nesting: Early returns keep nesting shallow, with straightforward loops and conditionals. Clarity of intent: The class documentation explains map conversion, but unrelated names such as createAccount, findWindow, balance, and cachedAccount obscure actual roles. The call to addToMap has no corresponding method in MapEntry, which defines readNode instead; renamed override methods also conflict with the expected interface contract, further confusing readers. Code length: Reasonably concise for the conversion process, though intermediate entries add complexity. Action granularity: Most lines perform a single action, making individual operations easy to inspect. Reading flow: The source-check, element-conversion, and target-construction sequence is natural, but misleading identifiers and inconsistent method names repeatedly interrupt comprehension.
Run 2
Code Structure: The converter is logically divided into conversion logic, helpers, and an entry holder, although addToMap is called while the holder defines readNode, disrupting coherence. Nesting: Shallow loops and guard clauses keep control flow easy to follow. Clarity of intent: The class documentation explains map conversion, but misleading names such as createAccount, removeRecord, balance, and cachedAccount obscure actual responsibilities. Code length: Reasonably concise, with useful helper extraction, though intermediate entry storage adds reading overhead. Action granularity: Most lines perform a single action; expressions remain manageable. Reading flow: The overall sequence is natural—check input, convert entries, determine whether copying is needed, build the result—but inconsistent naming forces frequent reinterpretation. Renamed interface methods also make the intended contract harder to recognize.
Run 3
Code Structure: The class separates conversion logic, helper methods, and entry storage logically, but the call to addToMap does not match the defined readNode method, disrupting coherence. Nesting: Shallow loops and guard clauses keep control flow easy to follow. Clarity of intent: The documentation explains map conversion, but misleading names such as createAccount, removeRecord, balance, and secureKey obscure actual responsibilities. Code length: Reasonably concise for the conversion and identity-preserving optimization, with limited duplication. Action granularity: Most lines perform a single action, making individual operations straightforward to inspect. Reading flow: The progression from null checks through conversion to map construction is natural, but unrelated identifiers force repeated interpretation. Interface-facing method names also appear inconsistent with ConditionalGenericConverter's expected contract, making the implementation harder to understand and trust.