Sample
pyint-fda717020a4e-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.759 | 0–1; higher is more readable |
| Mi | 0.682 | 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.179 | 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. | 742.8 | −24.512 |
| Source linesThe number of non-empty source lines. | 24 | +9.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. | 4.762 | −7.142 |
Intercept 8.87 + feature contributions = -13.185 (log-odds).
Score = sigmoid(-13.185) = 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. | 46.92 | +1.678 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.08 | +0.165 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 25 | +0.151 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 24 | −0.13 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 24 | +0.093 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 23.708 | −0.078 |
Intercept 0.07 + feature contributions = 1.145 (log-odds).
Score = sigmoid(1.145) = 0.759.
| Score | 0.682 |
|---|
| Score | 20 |
|---|
Run 1
The code is clean and readable. It follows a logical structure with clear imports and a focused class definition. Nesting is minimal and intent is unambiguous for each method. The use of type hints, __slots__, and a class-level key attribute demonstrates good design and reduces ambiguity. Each method performs a single action, and the flow is natural (check → serialize → deserialize). Although it omits the parent class definition, the code is concise and easy to follow.
Run 2
The code is highly readable and well-structured. It has a clear, logical organization with a single class definition and focused methods. Nesting is non-existent, keeping the code flat and easy to follow. Each function has a clear, singular purpose—type checking, encoding to JSON, and decoding from JSON—making the intent obvious. The code is concise, using `__slots__` and direct returns without unnecessary verbosity. Each method body contains one primary action per line, preserving clarity. Imports are grouped and specific rather than wildcard, aiding comprehension. The reading flow is natural: class declaration, then behaviors ordered logically. Minor deductions for lack of docstrings or type annotations on method parameters/return types, which could slightly improve clarity for less experienced readers, but overall this is exemplary readable code.
Run 3
The code is highly readable. It has a clear, logical structure with imports grouped by source (standard library, third-party, local), followed by a single class definition. Nesting is minimal: only flat method bodies with no conditional or loop indentation. Intent is explicit—each method name (`check`, `to_json`, `to_python`) directly describes its purpose, and the class name `TagBytes` clearly indicates it handles byte serialization. Code length is concise; there are no redundant lines or overly verbose expressions. Action granularity is appropriate: each line performs one focused operation, such as encoding then decoding ASCII on separate lines for clarity. Reading flow is natural, progressing from imports to class definition to simple method implementations. Minor deductions could be argued for the reliance on external base classes and possible type hint gaps, but overall the code is exceptionally clear and maintainable.
Run 1
Code Structure: The class is logically organized into type checking, serialization, and deserialization methods, although several imports are unused in this snippet and JSONTag is not visibly defined or imported. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Class and method names clearly communicate bytes conversion using Base64; the key " b" is unexplained, and broad t.Any annotations provide limited type information. Code length: The implementation is concise, though the import section is disproportionately long. Action granularity: Each statement occupies its own line, and the encoding-and-decoding chain is short and understandable. Reading flow: The check-to-JSON-to-Python ordering is natural, with consistent formatting and clear method boundaries.
Run 2
Code Structure: Imports precede a compact class with logically organized type-checking, serialization, and deserialization methods. Nesting: Flat methods with no branching or loops make the code easy to follow. Clarity of intent: TagBytes, check, to_json, and to_python clearly communicate byte tagging and Base64 conversion, though the opaque key " b" and undefined-in-snippet JSONTag require external context. Code length: The implementation is concise, but several imports are unused in this snippet and add visual clutter. Action granularity: Each statement performs one clear action; the chained encoding and decoding expression remains straightforward. Reading flow: The progression from checking the type to converting in each direction is natural. Additional spacing between import groups and the class would improve presentation.
Run 3
Code Structure: The class logically groups byte-type checking and serialization/deserialization into separate methods. Nesting: The code is flat, with no nested conditionals or loops. Clarity of intent: Class and method names clearly indicate byte handling and conversion, although the opaque key " b" and externally defined JSONTag require context. Code length: The implementation is concise, but several imports are unused in this snippet and add clutter. Action granularity: Statements generally perform one action per line; the encode/decode chain remains simple and readable. Reading flow: Imports followed by class configuration and short methods provide a natural progression, though additional spacing between import groups and before the class would improve readability.