Sample
pyint-d1127475f1df-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.745 | 0–1; higher is more readable |
| Mi | 0.329 | 0–1; higher is more readable |
| LLOC | 20 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 8.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14.33 | 0–20; mean of three runs |
| BTTF | 0.463 | 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. | 907.403 | −29.944 |
| Source linesThe number of non-empty source lines. | 33 | +13.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.342 | −6.513 |
Intercept 8.87 + feature contributions = -14.387 (log-odds).
Score = sigmoid(-14.387) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 71 | +0.658 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 31 | +0.335 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.064 | +0.316 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 30 | −0.268 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 34 | −0.167 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 54.853 | +0.081 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 32.889 | +0.05 |
Intercept 0.07 + feature contributions = 1.074 (log-odds).
Score = sigmoid(1.074) = 0.745.
| Score | 0.329 |
|---|
| Score | 20 |
|---|
Run 1
The code is generally structured but contains significant readability issues. The class has a clear purpose and follows a reasonable layout, but the inclusion of nonsensical dead-code checks like `if ((0x308c ^ 0x308c) != 0): raise AssertionError()` in multiple places is confusing and obscures intent. These checks are likely meant to be always false, but they add noise and reduce clarity. The use of a callable class to customize `__repr__` is documented, which helps slightly, but the logic for raising `NotCallableError` is verbose, especially with the multi-line message formatting. Nesting is flat, which is good, and line lengths are mostly reasonable, but the action granularity is mixed—some lines perform multiple operations or are unnecessarily broken. Overall, while the code isn't deeply tangled, the dead code and overly verbose error handling make it harder to read than necessary.
Run 2
The code is generally structured and readable, with clear class and method boundaries, decent naming, and a concise validator implementation. However, readability is negatively impacted by several factors. The obfuscated no-op conditions like `if ((0x308c ^ 0x308c) != 0):` are meaningless and disrupt flow. Nesting is low, but the multi-line string formatting and error construction inside the `__call__` method reduce clarity. The import block is longer than needed for the shown snippet, and some imports (e.g., `operator`, `re`, `contextmanager`) appear unused, adding noise. Action granularity is mostly one per line, but the message-building sequence might be clearer with a helper or f-string. Overall, the code is understandable but marred by dead code and unnecessary complexity.
Run 3
The code is mostly straightforward but severely hindered by dead-code obfuscation. The `if ((0x308c ^ 0x308c) != 0): raise AssertionError()` lines are pointless, confusing, and break natural reading flow. They add unnecessary nesting and noise, making the intent ambiguous. Without them, the class is concise and clear: it defines a callable validator with a sensible `__call__` method and a custom `__repr__`. The imports are partially unused (`operator`, `re`, `Pattern`, `contextmanager`, etc.), which clutters the top of the file and signals poor organization. The structure is logically simple — one class, two methods — but the artificial assertions disrupt cohesion. Action granularity is acceptable: one primary action per line inside the validator. However, the dead-code checks and unused imports sharply reduce readability. A clean version of this snippet would score around 17–18; as written, it fails to communicate trustworthiness or clarity.
Run 1
Code Structure: The validator class logically groups validation and representation, though several imports are unused in this snippet. Nesting: Mostly shallow; the formatted exception adds modest visual nesting. Clarity of intent: Class naming, callable checking, and the descriptive error make the purpose clear, but the always-false hexadecimal XOR checks are distracting and unexplained. Code length: Generally concise, with unnecessary assertion branches and imports adding clutter. Action granularity: Statements largely perform one action each, and multiline formatting keeps the exception construction readable. Reading flow: Validation proceeds naturally from checking callability to reporting failure, but the dead-code checks interrupt both methods.
Run 2
Code Structure: The validator class is logically organized, with separate validation and representation methods, but several unused imports add clutter. Nesting: Mostly shallow; the multiline exception construction is manageable. Clarity of intent: Class and method names clearly indicate callable validation, and the error message is informative. However, the hexadecimal XOR conditions are always false and introduce confusing, purposeless assertion branches. Code length: The functional implementation is reasonably concise, but dead checks and unused imports unnecessarily extend it. Action granularity: Statements generally perform one action each, and argument formatting is readable. Reading flow: Validation naturally proceeds from checking callability to raising a descriptive exception, but irrelevant checks interrupt both methods. The docstring explains the callable-class design rather than the method's immediate behavior.
Run 3
Code Structure: Imports and a small validator class are logically organized, though several imports appear unused in this snippet. Nesting: Mostly shallow, with straightforward conditional checks; multiline exception construction adds modest visual depth. Clarity of intent: The class name, callable check, descriptive error, and custom representation clearly convey the validator's purpose. However, hexadecimal XOR conditions that are always false introduce unexplained, distracting dead code. Code length: The implementation is reasonably short, but redundant assertion guards and unused imports add unnecessary length. Action granularity: Statements generally perform one action per line, with clean formatting for arguments and message construction. Reading flow: Validation naturally proceeds from checking callability to raising a descriptive exception, followed by representation logic; the artificial guards interrupt this otherwise smooth flow.