Source code
@Override
public void startingCollectionElements(CollectionElementDefinition elementDefinition) {
final Type elementType = elementDefinition.getType();
log.tracef(
"%s Starting collection element graph : %s",
StringHelper.repeat( ">>", fetchSourceStack.size() ),
elementDefinition.getCollectionDefinition().getCollectionPersister().getRole()
);
final CollectionReference collectionReference = currentCollection();
final CollectionFetchableElement elementGraph = collectionReference.getElementGraph();
if ( elementType.isAssociationType() || elementType.isComponentType() ) {
if ( elementGraph == null ) {
throw new IllegalStateException(
"CollectionReference did not return an expected element graph : " +
elementDefinition.getCollectionDefinition().getCollectionPersister().getRole()
);
}
if ( !elementType.isAnyType() ) {
pushToStack( (ExpandingFetchSource) elementGraph );
}
}
else {
if ( elementGraph != null ) {
throw new IllegalStateException(
"CollectionReference returned an unexpected element graph : " +
elementDefinition.getCollectionDefinition().getCollectionPersister().getRole()
);
}
}
}
Run 1
The code is generally readable with clear intent, good structure, and moderate nesting. Each action is on its own line or logically grouped, and the flow is natural. However, readability is slightly reduced by repeated verbose calls to `elementDefinition.getCollectionDefinition().getCollectionPersister().getRole()` and by somewhat long conditionals. The trace formatting string and indentation are slightly awkward but acceptable. Overall, it is understandable and maintainable.
Run 2
The code is moderately readable. It uses good naming and separates logging, state retrieval, and branching into distinct blocks. However, it suffers from nesting (up to 3 levels), duplicated exception messages, and moderately long lines. The repeated access to collection persister roles and the packed throw statements reduce clarity and action granularity. While the overall purpose is understandable, extracting helper methods for exception creation and simplifying the nested conditionals would improve readability. The control flow is logical but not as flat or concise as it could be.
Run 3
The code is generally readable with clear intent and good structure. It uses a flat, logical flow with only one level of nesting inside the main if/else branches. Method and variable names are descriptive. However, there are some issues: the repeated expression for retrieving the collection role appears three times, making the code longer than necessary and slightly harming readability. The tracef call with its multi-line arguments interrupts the reading flow slightly. Action granularity is mostly good, though some lines are long. Overall, the code is maintainable and understandable, but could be improved by extracting the repeated role retrieval into a local variable or helper method.
Run 1
Code Structure: Logically organized into initialization, logging, graph validation, and stack updates. Nesting: Moderate two-level conditionals are manageable, though the nested else could become an else-if. Clarity of intent: Descriptive variable names and explicit exception messages explain the expected graph invariants; the special treatment of any types requires domain knowledge. Code length: Reasonably concise, but the repeated collection-persister role lookup adds verbosity. Action granularity: Statements generally perform one action each, with multiline calls keeping long expressions readable. Reading flow: Execution proceeds naturally from type inspection to validation and stack manipulation, although repeated method chains and multiline formatting slightly interrupt scanning.
Run 2
Code Structure: Logically organized into type retrieval, logging, graph retrieval, validation, and stack update. Nesting: Moderate two-level conditionals are manageable, though an else-if could flatten the final branch. Clarity of intent: Descriptive names and specific exception messages clarify expected graph behavior; domain-specific type rules and the cast require contextual knowledge. Code length: Reasonably concise, but the repeated collection-role lookup adds verbosity. Action granularity: Each statement performs a distinct action, with multiline calls formatted clearly. Reading flow: Natural top-to-bottom progression and consistent spacing aid scanning, although repeated accessor chains and negative conditions slightly interrupt the flow.
Run 3
Code Structure: Logically organized into type retrieval, logging, graph retrieval, validation, and stack updates. Nesting: Moderate nesting is manageable, though the else block could be flattened into an else-if. Clarity of intent: Descriptive names and explicit exception messages explain expected graph behavior; domain-specific type checks and the cast require contextual knowledge. Code length: Reasonably concise, but repeated collection-role lookup and similar exception construction add verbosity. Action granularity: Each statement performs a distinct action, with multiline formatting keeping longer calls readable. Reading flow: Follows a natural sequence from setup to conditional handling, although repeated method chains and nested checks slightly interrupt scanning.