Sample

Schnappinger/argoUML/org.argouml.uml.cognitive.critics.CrNoIncomingTransitions

Human rating uses the original dataset scale.

Human3.71
Lines160

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
44.8Δ 3.6
Scalabrino0.7030–1; higher is more readable
38.7Δ 2.6
Dorn0.2570–1; higher is more readable
45.2Δ 4.0
Mi0.5590–1; higher is more readable
44.9Δ 3.6
LLOC43Logical lines; fewer is more readable
41.1Δ 0.2
DeepSeek V4 Pro15.670–20; mean of three runs
43.9Δ 2.6
GPT-6.1 Sol160–20; mean of three runs
38.9Δ 2.3
BTTF0.4760–1; higher is more readable
42.6Δ 1.3
Human3.711–4; original rating
41.3

Views

Source code

/* $Id: CrNoIncomingTransitions.java 19577 2011-06-22 20:37:05Z linus $ ***************************************************************************** * Copyright (c) 2009 Contributors - see below * All rights reserved. This program and the accompanying materials * are made available under the terms of the Eclipse Public License v1.0 * which accompanies this distribution, and is available at * http://www.eclipse.org/legal/epl-v10.html * * Contributors: * mvw ***************************************************************************** * * Some portions of this file was previously release using the BSD License: */ // Copyright (c) 1996-2009 The Regents of the University of California. All // Rights Reserved. Permission to use, copy, modify, and distribute this // software and its documentation without fee, and without a written // agreement is hereby granted, provided that the above copyright notice // and this paragraph appear in all copies. This software program and // documentation are copyrighted by The Regents of the University of // California. The software program and documentation are supplied "AS // IS", without any accompanying services from The Regents. The Regents // does not warrant that the operation of the program will be // uninterrupted or error-free. The end-user understands that the program // was developed for research purposes and is advised not to rely // exclusively on the program for any reason. IN NO EVENT SHALL THE // UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, // SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, // ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF // THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF // SUCH DAMAGE. THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY // WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF // MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE // PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF // CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, // UPDATES, ENHANCEMENTS, OR MODIFICATIONS. package org.argouml.uml.cognitive.critics; import java.util.Collection; import java.util.HashSet; import java.util.Set; import org.argouml.cognitive.Designer; import org.argouml.model.Model; import org.argouml.uml.cognitive.UMLDecision; /** * A critic to detect whether a state has no incoming transitions. * <p> * Also a transition to a state contained in the design material * counts as an "incoming" transition thanks to issue 689. * * @author jrobbins */ public class CrNoIncomingTransitions extends CrUML { /** * Constructor. */ public CrNoIncomingTransitions() { setupHeadAndDesc(); addSupportedDecision(UMLDecision.STATE_MACHINES); addTrigger("incoming"); } /** * This is the decision routine for the critic. * * @param dm is the design material, i.e. the * UML entity that is being checked. * @param dsgr is for future development and can be ignored. * * @return boolean problem found */ @Override public boolean predicate2(Object dm, Designer dsgr) { if (!(Model.getFacade().isAStateVertex(dm))) { return NO_PROBLEM; } /* Now we are sure dm is a StateVertex. */ if (Model.getFacade().isAPseudostate(dm)) { Object k = Model.getFacade().getKind(dm); if (k.equals(Model.getPseudostateKind().getChoice())) { return NO_PROBLEM; } if (k.equals(Model.getPseudostateKind().getJunction())) { return NO_PROBLEM; } if (k.equals(Model.getPseudostateKind().getInitial())) { return NO_PROBLEM; } } if (!Model.getFacade().isAState(dm)) { return NO_PROBLEM; } /* Now we are sure dm is a State. */ Object sm = Model.getStateMachinesHelper().getStateMachine(dm); if (sm != null && Model.getFacade().getTop(sm) == dm) { /* If dm is the top state of the statemachine, then it is * not supposed to have incoming transitions. */ return NO_PROBLEM; } Collection incoming = Model.getFacade().getIncomings(dm); if (incoming.size() > 0) { return NO_PROBLEM; } if (!Model.getFacade().isACompositeState(dm)) { return PROBLEM_FOUND; } /* Now we are sure dm is a Composite State. */ /* Issue 689: Look for a transition that arrives * at a sub-state of the composite state: */ Collection transitions = Model.getFacade().getTransitions(sm); for (Object t : transitions) { Object sourceState = Model.getFacade().getSource(t); Object targetState = Model.getFacade().getTarget(t); if (!isSomeSubvertexOf(sourceState, dm) && isSomeSubvertexOf(targetState, dm)) { return NO_PROBLEM; } } return PROBLEM_FOUND; } /** * Test if a state is contained within a composite state recursively. * This is done by checking if the parent of the subject * equals the composite, or the parent of the parent, etc. * * @param subject the StateVertex that is investigated * @param composite the Composite state that may or may not contain the subject * @return true if and only if the given composite contains recursively the given subject */ private boolean isSomeSubvertexOf(Object subject, Object composite) { Object c = subject; while (c != null) { if (c == composite) { return true; } c = Model.getFacade().getContainer(c); } return false; } /* * @see org.argouml.uml.cognitive.critics.CrUML#getCriticizedDesignMaterials() */ @Override public Set<Object> getCriticizedDesignMaterials() { Set<Object> ret = new HashSet<Object>(); ret.add(Model.getMetaTypes().getStateVertex()); return ret; } }

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.3252.079−107.319
Source linesThe number of non-empty source lines.160+64
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.94−7.41

Intercept 8.87 + feature contributions = -41.859 (log-odds).
Score = sigmoid(-41.859) = 0.

Score0.703

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.161−4.664
Indentation frequencyHow rapidly indentation changes from line to line.96+2.583
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.159.904+1.825
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.96−1.782
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.92.963+0.695
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.047+0.483
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.92.963−0.272

Intercept 0.07 + feature contributions = -1.062 (log-odds).
Score = sigmoid(-1.062) = 0.257.

Score0.559
Score43
Run 1

The code is well-structured and readable. It follows a clear logical organization, with the predicate2 method effectively using guard clauses to handle different cases. Nesting is minimal, with only one level of indentation inside loops. The naming conventions are clear, and the comments explain the logic without being excessive. Action granularity is appropriate, with one main action per line. The reading flow is natural, allowing a developer to understand the critic's logic step-by-step. However, the method could be slightly more concise by combining some conditions, and the isSomeSubvertexOf method lacks null-safety for the subject parameter. Overall, the code demonstrates good readability and maintainability.

Run 2

The code has a clear overall structure with logical method separation and meaningful names. However, readability is significantly reduced by the `predicate2` method's multiple early returns and nested conditionals, which make the flow harder to follow despite comments attempting to explain state. The method mixes different levels of abstraction—checking pseudostate kinds, verifying top state, checking incoming transitions, then looping through transitions—without breaking them into helper methods. The `isSomeSubvertexOf` helper is well-extracted and clear. The code is not deeply nested (max 2-3 levels), and most lines perform a single action. Comments are generally helpful but some are redundant or verbose. Overall, the code is moderately readable but could benefit from decomposing `predicate2` into smaller, named boolean checks.

Run 3

The code is well-structured and highly readable. It has clear separation of concerns with a single public predicate method and a private helper. Nesting is minimal—early returns flatten the logic effectively. Intent is clear from method names and descriptive comments, especially the 'NO_PROBLEM' early exits. Action granularity is mostly one action per line, with logical grouping in the pseudostate checks. Reading flow is natural: guard clauses lead to the core logic, and comments explain non-obvious decisions. Minor deductions: some repetition in pseudostate kind checks could be condensed, and the long license header slightly detracts from readability. Overall, a clean, maintainable critic implementation.

Run 1

Code Structure: The class is logically organized into initialization, detection logic, a containment helper, and metadata reporting. Nesting: Guard clauses keep the main routine mostly flat; nested pseudostate checks and loop conditions remain manageable. Clarity of intent: Descriptive class and helper names, explicit result constants, and explanatory comments communicate the purpose well. Abbreviated variables such as dm, sm, k, and c, raw collections, and repeated facade calls reduce immediate clarity. Code length: Functional code is reasonably concise, although repetitive pseudostate checks and extensive license boilerplate increase reading effort. Action granularity: Statements generally perform one action per line, with only a few compound conditions requiring extra attention. Reading flow: Checks progress naturally from eligibility and exceptions to incoming transitions and composite-state handling. Inconsistent indentation and a long conditional slightly disrupt otherwise clear formatting.

Run 2

Code Structure: Well-organized class with separate initialization, detection, containment-checking, and metadata methods. Nesting: Early returns keep the main routine mostly flat; nested pseudostate checks and the traversal loop remain manageable. Clarity of intent: The class description, explanatory comments, and named result constants clearly communicate the purpose, although abbreviated variables such as dm, sm, k, and c and generic Object types reduce clarity. Code length: Functional code is reasonably concise, but repetitive pseudostate checks, extensive license text, and some redundant comments add reading overhead. Action granularity: Statements generally perform one action per line, with a single compound condition that is somewhat long. Reading flow: Validation, exemptions, incoming-transition checks, and composite-state handling follow a natural sequence. Mixed tab/space indentation, raw collections, repeated facade calls, and long lines slightly disrupt readability.

Run 3

Code Structure: Methods are logically separated into initialization, detection, containment checking, and metadata. Nesting: Guard clauses and early returns keep nesting shallow, with only modest nesting for pseudostates and transition checks. Clarity of intent: The class documentation, explanatory comments, and descriptive helper name make the purpose clear; abbreviated variables such as dm, sm, k, and c and raw Collection types reduce clarity. Code length: Functional code is reasonably concise, though repetitive pseudostate checks and extensive license text increase reading overhead. Action granularity: Statements generally perform one action per line, and the compound transition condition remains understandable. Reading flow: Checks progress naturally from exclusions to incoming transitions and composite-state handling, but inconsistent indentation, repeated facade calls, and a long conditional slightly disrupt scanning.