Sample
int-5b8f54b1bde7-I07
Insert deterministic runtime-dead branches into callable bodies
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.67 | 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
This interface is highly readable. The structure is logical, with a clear class-level Javadoc, constants, and method declarations separated by whitespace. Nesting is nonexistent. The intent of each constant and method is explicitly documented. Code length is appropriate—each constant is a single line, and methods are concise. Action granularity is ideal: one constant assignment or method signature per line. The reading flow is natural, moving from constants to signing, then decrypting. Minor deductions: the long constant names are necessary but slightly visually dense, and the first Javadoc could be more formally worded. Overall, this code is clear and maintainable.
Run 3
This code is highly readable. It has a clear, logical structure with imports, an interface declaration, constant definitions, and method signatures in a natural order. Nesting is minimal—no conditional blocks or deep indentation. The intent is explicitly stated in both the class-level Javadoc and method-level Javadoc, which clarify the purpose and constraints (e.g., BoringSSL-only, non-null return values). The code is concise: constants are imported from a backing library rather than redefined, and the methods have a single, well-defined purpose. Each constant is on its own line, and each method declaration is separated by whitespace, aligning with one-action-per-line principles. The reading flow is top-down and intuitive: first the interface purpose, then supported algorithms, then the two operations with their parameters and return types. The only minor drawbacks are the repetitive constant naming and long lines for constants, which slightly reduce skim-ability, but overall it is an exemplary model of clean API design.
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 algorithm constants and method names make the purpose clear; Javadoc explains parameters and return requirements, though references to a 'given key' are slightly ambiguous because no key parameter is present. Code length: Concise for an interface; repetitive constant declarations are appropriate rather than unnecessary. Action granularity: Each constant and method declaration occupies its own line. Reading flow: Natural progression from supported algorithms to signing and decryption operations. Minor drawbacks include the dense constant block, missing spacing between package and imports, and informal or awkward documentation wording such as 'atm' and 'during the decrypting'.
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 constant and method names plus parameter and return documentation clearly communicate the API's purpose; informal wording such as 'atm' and references to an unspecified key slightly reduce precision. Code length: Concise for the functionality exposed, although repetitive constant declarations occupy much of the interface. Action granularity: Each constant and method declaration appears on its own line, avoiding combined actions. Reading flow: Natural progression from supported algorithms to signing and decryption operations; blank lines between import groups and visual grouping of algorithm families would improve scanning.
Run 3
Code Structure: The interface is logically organized into imports, algorithm constants, and documented method declarations. Nesting: Completely flat apart from the interface scope, making it easy to scan. Clarity of intent: Descriptive names and Javadoc clearly explain signing and decryption, although the introductory RSA qualification is ambiguous and key selection is implicit. Code length: Concise for its purpose; the repetitive constants are justified API definitions. Action granularity: Each line contains a single declaration, with no bundled operations. Reading flow: Constants precede related operations naturally, and consistent formatting supports readability. Minor improvements would include separating the package and import sections with blank lines, grouping constants by algorithm family, and replacing informal wording such as 'atm' in the documentation.