Sample

int-f9ecd91cb4d8-I08

Select one of ten high-readability unrelated code templates per class

Matched original source

Lines45

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.9460–1; higher is more readable
Dorn0.5590–1; higher is more readable
Mi0.2750–1; higher is more readable
LLOC2Logical lines; fewer is more readable
DeepSeek V4 Pro17.670–20; mean of three runs
GPT-6.1 Sol180–20; mean of three runs
BTTF0.6850–1; higher is more readable

Views

Source code

package io.netty.handler.ssl; import io.netty.internal.tcnative.SSLPrivateKeyMethod; import io.netty.util.internal.UnstableApi; import javax.net.ssl.SSLEngine; /** * Allow to customize private key signing / decrypting (when using RSA). Only supported when using BoringSSL atm. */ @UnstableApi public interface OpenSslPrivateKeyMethod { int SSL_SIGN_RSA_PKCS1_SHA1 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA1; int SSL_SIGN_RSA_PKCS1_SHA256 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA256; int SSL_SIGN_RSA_PKCS1_SHA384 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA384; int SSL_SIGN_RSA_PKCS1_SHA512 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_SHA512; int SSL_SIGN_ECDSA_SHA1 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SHA1; int SSL_SIGN_ECDSA_SECP256R1_SHA256 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SECP256R1_SHA256; int SSL_SIGN_ECDSA_SECP384R1_SHA384 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SECP384R1_SHA384; int SSL_SIGN_ECDSA_SECP521R1_SHA512 = SSLPrivateKeyMethod.SSL_SIGN_ECDSA_SECP521R1_SHA512; int SSL_SIGN_RSA_PSS_RSAE_SHA256 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PSS_RSAE_SHA256; int SSL_SIGN_RSA_PSS_RSAE_SHA384 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PSS_RSAE_SHA384; int SSL_SIGN_RSA_PSS_RSAE_SHA512 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PSS_RSAE_SHA512; int SSL_SIGN_ED25519 = SSLPrivateKeyMethod.SSL_SIGN_ED25519; int SSL_SIGN_RSA_PKCS1_MD5_SHA1 = SSLPrivateKeyMethod.SSL_SIGN_RSA_PKCS1_MD5_SHA1; /** * Signs the input with the given key and returns the signed bytes. * * @param engine the {@link SSLEngine} * @param signatureAlgorithm the algorithm to use for signing * @param input the digest itself * @return the signed data (must not be {@code null}) * @throws Exception thrown if an error is encountered during the signing */ byte[] sign(SSLEngine engine, int signatureAlgorithm, byte[] input) throws Exception; /** * Decrypts the input with the given key and returns the decrypted bytes. * * @param engine the {@link SSLEngine} * @param input the input which should be decrypted * @return the decrypted data (must not be {@code null}) * @throws Exception thrown if an error is encountered during the decrypting */ byte[] decrypt(SSLEngine engine, byte[] input) throws Exception; }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.

Score0.946

Feature contributions

FeatureValueContribution
(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.

Score0.275
Score2
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 highly readable. It has a clear structure: package declaration, imports, interface documentation, constants, and method signatures are logically organized. There is no nesting, and intent is explicit—both the interface's purpose and each method's role are documented with Javadoc. The constant declarations, though numerous, follow a consistent pattern and simply forward values from an underlying library, which is concise given the context. Each constant occupies one line, and method signatures are clean with one parameter per line in Javadoc. The reading flow is natural: constants first, then methods with clear documentation. Minor deductions: the large number of constants could benefit from grouping comments, and the interface documentation could explain why the constants are defined rather than inherited. Overall, this is exemplary for API-style Java code.

Run 3

The code is highly readable. It has a clear, logical structure: package, imports, Javadoc, interface declaration, constants, and method signatures. Nesting is effectively flat since it is an interface with only constants and abstract methods. Intent is clearly communicated through the interface name and detailed Javadoc comments that explain parameters, return values, and exceptions. Code length is appropriate; constants are concise and self-explanatory. Action granularity and reading flow are natural, following standard Java conventions. Minor deductions for a long line in the Javadoc and repetitive constant declarations, but these do not significantly impact overall readability.

Run 1

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; references to a 'given key' are slightly ambiguous because no key parameter is exposed. Code length: Concise for the API represented, although the repetitive constant block adds visual bulk. Action granularity: Each constant and method declaration occupies its own line. Reading flow: Natural progression from supported algorithms to operations, with whitespace separating methods; blank lines after the package declaration and between algorithm families would improve scanning.

Run 2

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 clearly communicate the interface's purpose; Javadoc explains parameters and return values, though the opening description is awkward and 'given key' is implicit rather than specified. Code length: Concise for its API surface; repetitive constant aliases are justified. Action granularity: Each constant or method declaration occupies its own line. Reading flow: Naturally progresses from supported algorithms to signing and decryption operations. Minor improvements include separating imports from the package declaration and visually grouping constants by algorithm family.

Run 3

Code Structure: Logically organized into imports, algorithm constants, and two documented interface methods. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive names and Javadoc clearly convey signing and decryption responsibilities, although the opening RSA wording is ambiguous and 'atm' is informal. Code length: Concise for its purpose; repetitive constant aliases are justified but visually dominate the interface. Action granularity: Each constant and method declaration occupies its own line. Reading flow: Natural top-to-bottom progression, with consistent formatting and clear separation between methods. Blank lines between import groups and related algorithm families would improve scanning.