Sample
pyint-dbf864a1fba1-I04
Replace names with deterministic minifier-style shortest identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.454 | 0–1; higher is more readable |
| Mi | 0.491 | 0–1; higher is more readable |
| LLOC | 99 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs |
| BTTF | 0.451 | 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. | 5827.841 | −192.319 |
| Source linesThe number of non-empty source lines. | 326 | +130.4 |
| 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.37 | −6.555 |
Intercept 8.87 + feature contributions = -59.604 (log-odds).
Score = sigmoid(-59.604) = 0.
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. | 326 | −10.506 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 147 | +4.347 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 325.8 | +4.144 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.032 | +0.635 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 75.162 | +0.408 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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. | 78.963 | +0.321 |
Intercept 0.07 + feature contributions = -0.183 (log-odds).
Score = sigmoid(-0.183) = 0.454.
| Score | 0.491 |
|---|
| Score | 99 |
|---|
Run 1
The code is largely unreadable due to cryptic single-letter parameter and variable names (e.g., l, m, a, n, o, p, c, B, A, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X). While docstrings remain descriptive, the implementation itself obscures intent, violating clarity of intent. The nested traversal in the environment variable loader uses multiple temporary variables and inline dict creation, increasing cognitive load. Action granularity is mostly one action per line, but the pervasive meaningless names negate this benefit. Code length is moderate but feels longer due to poor naming. Reading flow is severely disrupted because readers must constantly map letters to meanings. Structure is logical, but the variable naming alone renders the code nearly unreadable. Overall, the implementation is functional but extremely developer-hostile.
Run 2
The code suffers from severe readability issues due to meaningless parameter names (e.g., 'l', 'm', 'a', 'b', 'g', 'i') that obscure intent despite verbose docstrings describing proper names. Method names are also obfuscated, making the API incomprehensible without docstring reverse-engineering. While structure is mostly flat and action granularity is reasonable, the jarring contrast between clear, well-written prose in docstrings and cryptic identifiers destroys reading flow and clarity. The class is relatively concise, but this concision comes at the cost of self-documenting code. Renaming methods and parameters to match documented semantics would dramatically improve readability.
Run 3
The code is extremely difficult to read due to systematically obfuscated identifiers (e.g., 'a', 'b', 'c', 'l', 'm', 'n', 'o', 'p', 'q', 'r') that replace all meaningful method and parameter names. This destroys clarity of intent, making it impossible to understand what each method does without reading docstrings or tracing variable assignments. The docstrings contain the original meaningful names, but the code itself is a tangle of single-letter variables. Nesting and structure are mostly intact, but the obfuscated names break reading flow and action granularity, forcing readers to constantly map cryptic names back to docstrings. The code length is moderate and structure is logical, but these factors are overwhelmed by the lack of semantic naming.
Run 1
Code Structure: Configuration-loading responsibilities are logically separated into small methods within one cohesive class. Nesting: Mostly shallow, with early returns and continue statements keeping control flow manageable; nested environment-key traversal adds modest complexity. Clarity of intent: Single-letter method and variable names severely obscure purpose. Detailed docstrings help, but reference original method and parameter names that no longer match the implementation, making navigation confusing. Code length: Executable logic is reasonably concise, although extensive documentation dominates the listing and increases reading effort. Action granularity: Most lines perform one clear operation; the combined read, compile, and exec expression is denser. Reading flow: Consistent formatting, type annotations, and conventional exception handling support readability, but opaque identifiers and mismatched documentation repeatedly interrupt understanding.
Run 2
Code Structure: A cohesive configuration class separates loading and filtering operations into focused methods. Nesting: Generally shallow, with early returns and continue statements; nested environment-key traversal adds moderate complexity. Clarity of intent: Severely weakened by single-letter method and variable names. Docstrings explain functionality, but reference original method and parameter names that do not match the implementation, making navigation confusing. Code length: Implementations are reasonably concise, although extensive documentation dominates the file and includes distracting historical details. Action granularity: Most lines perform one operation; a few expressions combine reading, compilation, and execution. Reading flow: Consistent formatting, type annotations, comments, and conventional control flow help, but opaque identifiers and mismatched documentation force repeated cross-referencing.
Run 3
Code Structure: Configuration-loading responsibilities are logically separated into methods, but opaque method names obscure their relationships. Nesting: Mostly shallow, with early returns and continue statements; nested environment-key traversal adds moderate complexity. Clarity of intent: Docstrings, comments, and type hints explain functionality, but single-letter identifiers severely hinder understanding. Documentation references original method and parameter names that no longer match the implementation, and the silent keyword passed to c does not match its signature. Code length: Implementations are reasonably concise, although extensive documentation dominates the file and requires substantial scrolling. Action granularity: Most lines perform one action; the combined read, compile, and exec expression is a notable exception. Reading flow: Consistent formatting and localized error handling support sequential reading, but readers must repeatedly translate opaque identifiers and reconcile documentation with actual signatures.