Source code
package org.apache.kafka.security.authorizer;
import org.apache.kafka.common.internals.Plugin;
import org.apache.kafka.common.metrics.Metrics;
import org.apache.kafka.common.resource.Resource;
import org.apache.kafka.common.utils.Utils;
import org.apache.kafka.server.authorizer.Authorizer;
import java.util.Map;
public class AuthorizerUtils {
public static Plugin<Authorizer> create(String class2, Map<String, Object> con, Metrics met, String key, String rol) throws ClassNotFoundException {
Authorizer aut = Utils.newInstance(class2, Authorizer.class);
aut.configure(con);
return Plugin.wrapInstance(aut, met, key, "role", rol);
}
public static boolean is(String nam) {
return nam.equals(Resource.CLUSTER_NAME);
}
}
Run 1
The code suffers from poor readability across all criteria. The class and method names are vague (e.g., 'create', 'is', 'class2', 'con', 'met', 'rol') making the intent ambiguous. The method 'create' packs multiple actions (instantiation, configuration, wrapping) into a single line, violating action granularity. Parameter names like 'class2' and 'con' obscure their purpose. The 'is' method is misleading—it actually checks if a string matches the cluster resource name, not a boolean property. The code is concise but at the cost of clarity. There is no logical grouping of imports or proper naming conventions. The reading flow is disorganized due to cryptic abbreviations and hidden logic. Overall, the code is technically functional but requires significant mental effort to understand what it does and why.
Run 2
The code is highly unreadable due to extremely abbreviated parameter names ('con', 'met', 'key', 'rol', 'nam', 'aut'), which obscure intent. The method names 'create' and 'is' are too generic to convey purpose without reading the implementation. The reading flow is poor because the constructor call and configuration are packed into a single dense line. The 'is' method is a one-liner but its abbreviated name and parameter ('nam') make it ambiguous. The 'key' parameter is used but 'role' is hardcoded, which is confusing without additional context. While the file is short and not deeply nested, the lack of meaningful names and documentation severely hurts clarity and intent.
Run 3
The code suffers from severe readability issues. Variable names are cryptic and abbreviated (con, met, aut, nam, rol, class2), obscuring their purpose. The method 'is' is ambiguous and does not convey its intent of checking if a resource is a cluster. The method 'create' performs multiple actions (instantiation, configuration, wrapping) in a single line, violating action granularity. While the structure is simple and flat, the lack of descriptive naming, unclear intent, and condensed logic significantly impair readability and maintainability.
Run 1
Code Structure: A small utility class logically groups two simple methods, though their relationship is not immediately clear. Nesting: No nested control flow, making both methods easy to follow. Clarity of intent: Kafka types and API calls help explain the behavior, but abbreviated parameters such as class2, con, met, and rol reduce clarity; the method name is is particularly vague. Code length: Concise without unnecessary complexity. Action granularity: Each statement performs a distinct action on its own line, although the long create declaration is harder to scan. Reading flow: Instantiation, configuration, and wrapping follow a natural sequence. Missing spacing between package, imports, and the class slightly weakens visual organization.
Run 2
Code Structure: Two small utility methods are logically organized, although spacing between the package and imports would improve presentation. Nesting: No nested control flow, making both methods easy to follow. Clarity of intent: Authorizer creation and configuration are understandable, but abbreviated parameter names (con, met, rol, nam), class2, aut, and the vague method name is obscure meaning. Code length: Concise, with no unnecessary logic, though the create signature is long. Action granularity: Each statement performs a single clear action. Reading flow: Creation, configuration, and wrapping follow a natural sequence; weak naming is the main obstacle to readability.
Run 3
Code Structure: Two small, logically separated utility methods provide straightforward organization. Nesting: No nested control flow makes the code easy to follow. Clarity of intent: Calls reveal authorizer creation, configuration, and wrapping, but abbreviated names such as con, met, aut, and rol reduce clarity; class2 and the method name is are particularly vague. Code length: Concise without unnecessary statements, although the long create signature is harder to scan. Action granularity: Each statement performs one clear action. Reading flow: The create method follows a natural sequence, but missing spacing between the package, imports, and class, combined with cryptic naming, weakens readability.