Sample
int-0ffb65429cb7-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.946 | 0–1; higher is more readable |
| Dorn | 0.559 | 0–1; higher is more readable |
| Mi | 0.275 | 0–1; higher is more readable |
| LLOC | 2 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.685 | 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. | 965.73 | −31.869 |
| Source linesThe number of non-empty source lines. | 45 | +18 |
| 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.991 | −7.487 |
Intercept 8.87 + feature contributions = -12.486 (log-odds).
Score = sigmoid(-12.486) = 0.
| Score | 0.946 |
|---|
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. | 112.978 | −1.12 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 112.913 | +1.017 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.032 | +0.633 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 46 | −0.592 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 28 | +0.231 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 28 | −0.222 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 44.93 | +0.218 |
Intercept 0.07 + feature contributions = 0.236 (log-odds).
Score = sigmoid(0.236) = 0.559.
| Score | 0.275 |
|---|
| Score | 2 |
|---|
Run 1
The code is well-structured as a concise interface definition. Constants are logically grouped and consistently formatted, though the list is long. The interface avoids unnecessary nesting and has a clear purpose: defining a custom private key method for SSL operations. Method signatures are concise with clear parameter names and return types. Javadoc comments effectively document intent and behavior. Reading flow is natural, with constants first, then methods, and clear documentation separating them. Minor deductions result from repetitive constant declarations and slight verbosity in Javadoc, but overall readability is high.
Run 2
The code is well-structured and highly readable. It clearly defines an interface with a logical grouping of constants mapped from a native library, followed by two well-documented method signatures. Nesting is absent (flat structure), and each constant is on its own line, maintaining clear action granularity. Intent is explicit in both the interface name and Javadoc comments. The length is appropriate—each constant mapping is necessary, and the method declarations are concise. Reading flow is natural: imports, annotations, constants, then method signatures. Only minor deductions are for the long list of similar constants, which could benefit from grouping or comments separating algorithm families (RSA, ECDSA, etc.), and the overly brief class-level Javadoc, which omits usage details.
Run 3
The code is a well-structured interface definition with clear intent. Constants are grouped logically and delegated to a native library, avoiding duplication. Method signatures and Javadoc are concise and informative, with clear parameter descriptions. The code is flat, has minimal nesting, and maintains one action per line. The import statements and annotations are appropriately placed. Minor deductions: the long list of constants could benefit from group comments for RSA/ECDSA/EdDSA algorithms, and the Javadoc for decrypt could clarify 'RSA' context, but overall readability is high.
Run 1
Code Structure: Logically organized into imports, interface constants, and documented method declarations. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive constant and method names plus parameter and return documentation clearly communicate purpose, though references to a 'given key' are slightly ambiguous because no key parameter is exposed. Code length: Concise for an interface; repetitive constants are appropriate API declarations rather than unnecessary verbosity. Action granularity: Each constant and method declaration occupies its own line. Reading flow: Natural top-to-bottom progression, slightly weakened by tightly packed imports and constants without visual grouping by algorithm family. Minor informal wording such as 'atm' reduces documentation polish.
Run 2
Code Structure: Logically organized into imports, interface documentation, algorithm constants, and two documented methods. Nesting: Flat interface declarations with no nested control flow. Clarity of intent: Descriptive constants, method names, and Javadoc clearly communicate signing and decryption responsibilities, though the introductory RSA wording is ambiguous given the other signature algorithms. Code length: Concise for its purpose; repetitive constant aliases are justified but visually dense. Action granularity: Each constant and method declaration occupies its own line. Reading flow: Natural top-to-bottom progression, slightly weakened by missing spacing around imports and the lack of visual grouping among algorithm families.
Run 3
Code Structure: The interface is logically organized into imports, algorithm constants, and documented method declarations. Nesting: The code is flat, with no nested control flow. Clarity of intent: Descriptive names and parameter/return documentation clearly communicate signing and decryption responsibilities, although the introductory RSA wording is ambiguous given the non-RSA signing constants. Code length: Concise for its purpose; the repetitive constant aliases are justified but visually dense. Action granularity: Each constant and method declaration occupies its own line, making individual elements easy to identify. Reading flow: Constants precede operations naturally, and consistent formatting supports scanning. Blank lines between import groups and related algorithm families would improve readability slightly.