Sample
pyint-cca4353f6225-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.024 | 0–1; higher is more readable |
| Mi | 0.802 | 0–1; higher is more readable |
| LLOC | 188 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.528 | 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. | 15751.83 | −519.81 |
| Source linesThe number of non-empty source lines. | 461 | +184.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.187 | −6.281 |
Intercept 8.87 + feature contributions = -332.821 (log-odds).
Score = sigmoid(-332.821) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 462 | −15.322 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 418 | +13.721 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 418 | −9.171 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 460.91 | +6.033 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 87.351 | +0.605 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.054 | +0.418 |
| 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. | 87.959 | −0.06 |
Intercept 0.07 + feature contributions = -3.707 (log-odds).
Score = sigmoid(-3.707) = 0.024.
| Score | 0.802 |
|---|
| Score | 188 |
|---|
Run 1
The code has clear structure with logical organization into methods and properties, but suffers from several readability issues. The nesting is generally shallow, which is positive, except in _check_unique_target where the logic gets complex with multiple conditions. Clear intent is maintained through descriptive method names and docstrings. The code length is appropriate for the complexity of the Django ForeignObject implementation. Action granularity is mostly good, though some lines contain multiple operations. Reading flow is natural but interrupted by inconsistent style choices like using 0x1 and 0x0 instead of 1 and 0, which is confusing for numeric literals. The imports are well-organized but some are unused (Field, Q, LOOKUP_SEP, etc.), which reduces clarity. The _check_unique_target method is quite long and complex, making it harder to follow than necessary. The mix of % formatting and f-strings is inconsistent. Overall, this is professional-level Django code that could be more readable with better documentation in complex sections and consistent style choices.
Run 2
The code is a Django ForeignObject field implementation with reasonable structure. It follows consistent naming (e.g., _check_* methods) and each method serves one purpose. However, readability is hampered by several factors. The class is quite long (~350 lines), and some methods have significant nesting (e.g., _check_unique_target has 3-4 levels). Action granularity is mixed—some lines combine multiple operations (e.g., `return tuple(... for ... if ...)`). A few odd constructs like `0x1` and `0x0` for 1 and 0 reduce clarity. Some comments are helpful but sparse; many branches lack comments. Heavy use of Django meta APIs and tuple/list comprehensions makes the code dense. The imports are just listing modules, so less of an issue. Overall, comprehension requires good Django internals context—hence mid-range score.
Run 3
The code is generally well-structured and readable, with clear sectioning through class attributes and methods. The imports are organized logically, and method names are descriptive. However, readability is reduced by several factors: some methods like _check_to_fields_composite_pk and _check_unique_target contain deeply nested conditionals and complex logic that requires careful reading. The use of hexadecimal constants (0x1, 0x0) is obscure and reduces clarity. Some error messages contain long f-strings that make the code harder to scan. The get_class_lookups method uses metaprogramming that may be unclear to developers unfamiliar with Django internals. While the code follows good practices like single-purpose methods and meaningful variable names, the domain complexity and occasional cryptic constructs like merge_dicts and RECURSIVE_RELATIONSHIP_CONSTANT (undefined in this snippet) require significant Django knowledge to fully comprehend.
Run 1
Code Structure: Well-organized class with focused methods separating validation, serialization, field resolution, and relationship traversal. Nesting: Mostly shallow, aided by early returns, though validation and deconstruction contain several nested branches. Clarity of intent: Descriptive method names, comments, and docstrings explain complex behavior; Django-specific internals, undefined names in the excerpt, and unnecessary hexadecimal literals reduce accessibility. Code length: Long but largely justified by functionality; repeated error construction and wrapper properties add some verbosity. Action granularity: Statements generally perform one action, with multiline calls and comprehensions formatted clearly. Reading flow: Related methods are grouped naturally and formatting is consistent, although extensive imports, framework dependencies, and dense uniqueness checks interrupt easy scanning.
Run 2
Code Structure: Cohesive class with well-separated methods for validation, field resolution, serialization, and relationship traversal; the broad import list adds clutter. Nesting: Mostly shallow, aided by early returns, though validation and deconstruction contain several nested branches. Clarity of intent: Descriptive method names, docstrings, and explanatory comments communicate purpose well. Framework-specific metadata access requires Django knowledge, and hexadecimal literals for ordinary indices and counts unnecessarily obscure intent. Code length: The class is long but generally justified by its responsibilities; repeated error construction and verbose attribute chains could be simplified. Action granularity: Statements generally perform one action each, with comprehensions and multiline calls formatted clearly. Reading flow: Consistent formatting and sensible method grouping support natural reading, although complex uniqueness expressions and dependencies not defined in the excerpt interrupt comprehension.
Run 3
Code Structure: Well-organized class with focused methods separating validation, field resolution, metadata, and descriptor setup. Nesting: Mostly shallow, with early returns helping readability; validation and deconstruction contain some moderately nested branches. Clarity of intent: Descriptive method names, docstrings, and contextual comments explain complex ORM behavior. However, unexplained hexadecimal constants (0x0, 0x1), framework-specific terminology, and definitions absent from the snippet reduce standalone clarity. Code length: Substantial but largely justified by functionality; repeated error construction and numerous imports add some bulk. Action granularity: Statements generally perform one action each, and multiline expressions are consistently formatted. Reading flow: Related methods are grouped naturally, with clear spacing and predictable formatting, although dense uniqueness checks and long metadata access chains require careful reading.