Sample
pyint-8c94713ec084-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.85 | 0–1; higher is more readable |
| Mi | 0.573 | 0–1; higher is more readable |
| LLOC | 20 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.564 | 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. | 737.534 | −24.339 |
| Source linesThe number of non-empty source lines. | 31 | +12.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.373 | −6.559 |
Intercept 8.87 + feature contributions = -9.628 (log-odds).
Score = sigmoid(-9.628) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 88 | +0.615 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.05 | +0.454 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 30 | +0.301 |
| 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. | 88 | −0.062 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 31 | −0.061 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 30.775 | +0.02 |
Intercept 0.07 + feature contributions = 1.735 (log-odds).
Score = sigmoid(1.735) = 0.85.
| Score | 0.573 |
|---|
| Score | 20 |
|---|
Run 1
The code is well-structured with a single class definition containing a clear purpose. Nesting is minimal with one try-except block and an if statement. The intent is obvious: validate that a value belongs to a set of allowed options. The code is concise with no unnecessary verbosity. Action granularity is good—each logical operation is on its own line, like the try block, error message construction, and exception raising. Reading flow is natural: initialize, check membership, handle errors, raise exception if needed. The only minor deduction is the lack of type hints and a docstring, which would clarify the parameter types and the validator's contract for maintainers.
Run 2
The code is well-structured with clear separation of concerns: class-level attributes are defined first, followed by the core validation method, and a helper method for representation. Nesting is minimal—only one try/except block and one conditional—keeping the logic flat and easy to follow. Intent is explicit: the class validates membership with clear error messaging when values are invalid. The method names and docstrings (implicitly) convey purpose without ambiguity. Code length is appropriate for the functionality; no unnecessary verbosity. Action granularity is mostly one action per line, though the error-raising block combines multiple arguments across lines, which slightly reduces crispness but remains readable. Reading flow is natural: the `__call__` method proceeds linearly from input check to error raising, and `__repr__` provides a concise summary. Overall, the code is highly readable with minor, non-critical density in the exception construction.
Run 3
The code is highly readable. The class has a clear, single responsibility (validating membership) and uses a concise attrs-based definition. Nesting is minimal—only a single try/except and if block. Variable names are descriptive, and the error message is explicit and informative. Each line performs one logical action, and flow proceeds naturally. The only minor issue is the commented example inside the except clause, which slightly interrupts reading flow but is still helpful.
Run 1
Code Structure: The validator class is logically organized, separating attributes, validation, and representation; several unused imports add clutter. Nesting: Shallow try/except and a single conditional make control flow easy to follow. Clarity of intent: Descriptive names, an explanatory comment, and a precise error message clearly convey membership validation, although the distinction between options and _original_options is not explained. Code length: The implementation is concise, with modest verbosity in the multiline exception construction. Action granularity: Each statement performs one clear action. Reading flow: Validation proceeds naturally from checking membership to handling invalid values, followed by a straightforward representation method.
Run 2
Code Structure: The validator class is logically organized into attributes, validation behavior, and representation, although several imports are unused in this snippet. Nesting: Shallow try/except and a single conditional keep complexity low. Clarity of intent: Membership validation is explicit, with descriptive names and a helpful comment explaining the TypeError case; the distinction between options and _original_options is not fully explained. Code length: Concise overall, though the multiline exception construction is slightly verbose. Action granularity: Each statement performs one clear action, with message construction separated from raising the exception. Reading flow: Execution proceeds naturally from membership testing to error handling, with whitespace separating logical steps.
Run 3
Code Structure: The validator class is logically organized, with attributes, validation logic, and representation clearly separated, though several imports are unused in this snippet. Nesting: Shallow try/except and conditional blocks keep complexity low. Clarity of intent: Descriptive names and the TypeError example make membership validation easy to understand; the distinction between options and _original_options is not fully explained. Code length: The implementation is concise, although the multiline ValueError construction is slightly verbose. Action granularity: Each statement performs a single clear action. Reading flow: Execution proceeds naturally from membership testing to error handling, with consistent formatting and helpful whitespace.