Sample
pyint-169a4ecb2d28-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.839 | 0–1; higher is more readable |
| Mi | 0.318 | 0–1; higher is more readable |
| LLOC | 19 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.56 | 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. | 655.551 | −21.633 |
| Source linesThe number of non-empty source lines. | 25 | +10 |
| 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.578 | −6.867 |
Intercept 8.87 + feature contributions = -9.63 (log-odds).
Score = sigmoid(-9.63) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 78.731 | +0.466 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.055 | +0.41 |
| 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. | 81.923 | +0.195 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 26 | +0.116 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 24.771 | −0.064 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 23 | +0.058 |
Intercept 0.07 + feature contributions = 1.65 (log-odds).
Score = sigmoid(1.65) = 0.839.
| Score | 0.318 |
|---|
| Score | 19 |
|---|
Run 1
The code is well-structured with clear imports, proper use of frozen attrs, and a single-purpose validator class. Nesting is minimal, and each method has a clear intent. The __call__ method handles validation concisely with a clear error message, while __repr__ provides useful debugging info. However, readability could improve with a type hint for 'inst' (likely unused), a more descriptive docstring, and slightly more context around the class purpose. The mix of validation logic and repr in one small class is acceptable but could be separated for clarity. Overall, it's readable and maintainable with only minor improvements needed.
Run 2
The code is highly readable with clear logical organization. The `_NumberValidator` class uses `attrs` to reduce boilerplate, resulting in concise code. The `__call__` method has a single, clear purpose and virtually no nesting, following a flat structure. Error handling is straightforward with a clear f-string message. The `__repr__` method creates a descriptive validator representation. Minor deductions: the docstring in `__call__` doesn't fully explain the class's purpose, and the attribute names `compare_op` vs `compare_func` could be slightly more consistent. Overall, the code demonstrates excellent structural clarity, natural reading flow, and appropriate action granularity, making it easy to understand and maintain.
Run 3
The code is highly readable with a clear, single-purpose class. Structure is logical: imports organized, decorators succinctly define behavior. Nesting is minimal—only one conditional inside __call__. Intent is explicit via descriptive names like _NumberValidator, compare_op, compare_func. Length is concise without sacrificing clarity. Action granularity is appropriate: one meaningful operation per line, with the if-check and exception raising well-separated. Reading flow is natural, from imports through class definition to method implementations. Minor deductions: the docstring could better explain the class’s purpose, and the leading underscore signals internal use but without a module-level comment. The f-string is clear, though line length could be slightly long for some style guides. Overall, the code is well-factored, flat, and easy to follow.
Run 1
Code Structure: The validator class is logically organized, with attributes followed by validation and representation methods, although several imports are unused in this snippet. Nesting: Only one conditional is used, keeping the code flat and easy to follow. Clarity of intent: Descriptive names and the error message clearly communicate numeric-bound validation; the docstring explains the callable-class design rather than the method's behavior. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs one action, and error-message construction is separated from raising the exception. Reading flow: The progression from configuration to validation to representation is natural, though additional blank lines between imports and the class would improve visual separation.
Run 2
Code Structure: Imports, class attributes, validation logic, and representation are logically organized, though several imports are unused in this snippet. Nesting: Minimal nesting, with only a single conditional inside __call__. Clarity of intent: The class clearly validates a numeric comparison against a bound, supported by descriptive attribute names and an informative error message. The docstring explains the callable-class design rather than the method's validation behavior. Code length: Concise, with little unnecessary implementation code. Action granularity: Each line generally performs one action, and message construction is separated from raising the exception. Reading flow: Natural progression from configuration to validation to representation; additional spacing between imports and the class would slightly improve visual separation.
Run 3
Code Structure: The validator is logically organized into configuration fields, validation behavior, and representation, though several unused imports add clutter. Nesting: Minimal nesting makes control flow easy to follow. Clarity of intent: Descriptive names and the error message clearly communicate numeric-bound validation; the docstring explains the callable-class design rather than the method's behavior. Code length: The implementation is concise, with little unnecessary code beyond unused imports. Action granularity: Each line performs a single clear action. Reading flow: Fields followed by validation and representation create a natural progression, although additional blank lines around the class and import groups would improve visual separation.