Sample
pyint-140ed9846741-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.845 | 0–1; higher is more readable |
| Mi | 0.526 | 0–1; higher is more readable |
| LLOC | 23 | 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.486 | 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. | 1269.981 | −41.909 |
| Source linesThe number of non-empty source lines. | 44 | +17.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.639 | −6.959 |
Intercept 8.87 + feature contributions = -22.398 (log-odds).
Score = sigmoid(-22.398) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 41 | +0.681 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.911 | +0.598 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 45 | −0.557 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.064 | +0.317 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 43.852 | +0.203 |
| 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. | 86.956 | −0.018 |
Intercept 0.07 + feature contributions = 1.693 (log-odds).
Score = sigmoid(1.693) = 0.845.
| Score | 0.526 |
|---|
| Score | 23 |
|---|
Run 1
The code is well-structured and readable. It defines a single class with clear logical methods for combining lexeme objects. Nesting is minimal, with only a couple of single-level conditionals. The intent is evident: enable bitwise operators for combining lexeme expressions. The `_combine` method centralizes logic, avoiding duplication. Action granularity is appropriate—each method does one thing and uses concise expressions. Reading flow is natural, with the private helper method placed logically before the public operator overloads. A minor deduction for the inline comment about 'abusing' operators, which could be slightly clearer, and the error message concatenation could be simplified, but overall it's clean and maintainable.
Run 2
The code is well-structured and highly readable. It defines a clear base class with a single responsibility: combining Lexeme objects using bitwise operators. The _combine method consolidates shared logic, avoiding duplication across the four operator methods. Nesting is minimal, with only one conditional inside _combine. The intent is explicit: the class facilitates logical combination of lexemes, and the comment clarifies the deliberate use of bitwise operators for consistency with Django. Code length is concise, and each action is separated clearly, enhancing action granularity. Reading flow is natural, as methods are ordered logically: helper first, then public operators. Type checks and f-strings improve clarity. Minor deductions: the reversed parameter could be slightly more descriptive, and the TypeError string is split across lines, slightly interrupting flow. Overall, the code is clean, maintainable, and easy to understand.
Run 3
The code is generally well-structured and readable. It defines a single class with clear methods, uses consistent naming, and includes helpful documentation explaining the design decision to implement logical operators. The `_combine` method has mild nesting with a conditional, but it's minimal and logical. Each line performs a single action, contributing to clear action granularity. The reading flow is natural, proceeding from imports to class definition to method implementations. Minor deductions: the conditional in `_combine` could be slightly flatter, and the f-string error message is long but acceptable. Overall, the code demonstrates good practices: clear intent, logical organization, and appropriate length for its purpose.
Run 1
Code Structure: The class logically groups combination constants, shared validation, and operator overloads; however, many imports are unused in this snippet. Nesting: Simple conditionals keep nesting shallow. Clarity of intent: Descriptive names, an informative error, and a comment explain the logical-combination behavior, though the parameter name 'reversed' shadows a built-in and positional booleans require interpretation. Code length: Methods are concise, and the shared helper avoids duplicated logic. Action granularity: Each statement performs a single clear action; multiline formatting improves readability. Reading flow: Constants and the helper precede the operators, providing a natural progression. Minor spacing inconsistencies and references to externally defined types slightly reduce standalone readability.
Run 2
Code Structure: The class logically groups operator constants, shared combination logic, and operator overloads, avoiding duplication. Nesting: Flat methods and simple conditionals make control flow easy to follow. Clarity of intent: Descriptive names, explicit type validation, and an explanatory comment communicate logical lexeme combination, though the 'reversed' parameter shadows a built-in and CombinedLexeme is not defined in the snippet. Code length: Methods are concise, but numerous imports are unused in the displayed code. Action granularity: Each statement performs one clear action, with readable multiline formatting for the exception. Reading flow: Constants precede the helper and public operator methods in a natural sequence; minor spacing inconsistencies and external Django dependencies slightly reduce standalone readability.
Run 3
Code Structure: The class logically groups operator constants, shared combination logic, and operator overloads; several imports are unused in this excerpt and add clutter. Nesting: Minimal nesting and early returns make control flow easy to follow. Clarity of intent: Descriptive names, an explicit type error, and a contextual comment explain logical lexeme combination, though the parameter name 'reversed' shadows a built-in and positional booleans require some interpretation. Code length: Concise, with shared logic avoiding duplication across overloads. Action granularity: Each statement performs a single clear action, with long expressions sensibly split across lines. Reading flow: The progression from constants to implementation to public operators is natural and consistent.