| # Licensed to the Apache Software Foundation (ASF) under one |
| # or more contributor license agreements. See the NOTICE file |
| # distributed with this work for additional information |
| # regarding copyright ownership. The ASF licenses this file |
| # to you under the Apache License, Version 2.0 (the |
| # "License"); you may not use this file except in compliance |
| # with the License. You may obtain a copy of the License at |
| # |
| # http://www.apache.org/licenses/LICENSE-2.0 |
| # |
| # Unless required by applicable law or agreed to in writing, |
| # software distributed under the License is distributed on an |
| # "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| # KIND, either express or implied. See the License for the |
| # specific language governing permissions and limitations |
| # under the License. |
| |
| # Method to complex |
| DN_MethodTooComplex=Method is too complex |
| DESC_MethodTooComplex=The inspection reports method, whose <b>Cyclomatic Complexity</b> \ |
| exceeds a configurable value. The <i>Cyclomatic Complexity</i> measures a number \ |
| of potential branching points (or cycles) in a method. It is believed that methods \ |
| with high cyclomatic complexity usually do too much and should be split to several, \ |
| more focused, methods. Such complex methods are also prone to code duplication between \ |
| their execution paths and are hard to sustain. Usually it is recommended that cyclomatic \ |
| complexity of a method is 5 or below; less than 10 may be also acceptable for more elaborate \ |
| algorithms. |
| |
| # Too deep nesting |
| DN_MethodTooDeepNesting=Too deep nesting |
| DESC_MethodTooDeepNesting=Reports methods whose bodies contain statements nested <i>too deep</i>. \ |
| Such methods are less readable, contain indent space and allow less \ |
| screen space for code reading. Methods can be often refactored and split to \ |
| improve code readability. |
| |
| MethodComplexityCustomizer.limtLabel.text=Complexity limit: |
| OPTNAME_MethodComplexityLimit=Complexity limit |
| OPTDESC_MethodComplexityLimit= |
| OPTNAME_MethodDepthLimit=Statement depth limit |
| OPTDESC_MethodDepthLimit= |
| |
| # Method too long - lines or statements |
| DN_MethodTooLong=Method body is too long |
| DESC_MethodTooLong=Reports methods, which have too long body. Longer methods require scrolling back \ |
| and forth, and typically can be refactored into several methods called from a mediating method. \ |
| Splitting a long method into several named pieces may also help code reuse. Some coding practices even \ |
| demand that a method should fit a screen size, so it can be easily scanned and understood by the developer. |
| OPTNAME_MethodLinesLimit=Permitted number of lines |
| OPTDESC_MethodLinesLimit= |
| OPTNAME_MethodStatementsLimit=Permitted number of statements |
| OPTDESC_MethodStatementsLimit= |
| |
| # Method throws too many exception |
| DN_MethodTooManyExceptions=Method or constructor declares too many exceptions |
| DESC_MethodTooManyExceptions=Reports methods which declare many exceptions in their <b>throws</b> clause. Method \ |
| that produce a large number of exception types are hard to use, as the caller must handle all the outcomes \ |
| or complicate its own declaration with exceptions. The error handling code grows more complex. \ |
| <p/>The inspection also processes constructors. |
| OPTNAME_MethodExceptionsLimit=Allowed exception count |
| OPTDESC_MethodExceptionsLimit= |
| |
| # Method declares too may parameters |
| DN_MethodTooManyParameters=Method declares too many parameters |
| DESC_MethodTooManyParameters=Reports method that take too many parameters. Methods with large number of parameters \ |
| indicate a bad design. It's likely that yet more parameters will be added in the future, so the parameters \ |
| should be grouped into a Command Object, improving maintenance costs. Alternatively, the method could be refactored \ |
| into several methods, each doing part of the task and requiring less parameters at input. |
| OPTNAME_MethodParametersLimit=Allowed parameter count |
| OPTDESC_MethodParametersLimit= |
| |
| DN_CtorTooManyParameters=Constructor declares too many parameters |
| DESC_CtorTooManyParameters=Reports constructor that take too many parameters. Constructors typically take more parameters \ |
| than a regular method, especially when initializing a large object.<p/>Large number of parameters \ |
| indicate a bad design. It's likely that yet more parameters will be added in the future, so creational patterns like \ |
| Builder should be considered. |
| |
| OPTNAME_CtorParametersLimit=Allowed parameter count |
| OPTDESC_CtorParametersLimit= |
| |
| # Method with mulitple return statements |
| DN_MethodMultipleReturns=Method with multiple return points |
| DESC_MethodMultipleReturns=Reports methods, which exit at multiple places using <b>return</b> statement. \ |
| Such methods may be confusing and are \ |
| harder to refactor. The inspection can ignore conditional <b>guard returns</b> - a <b>return</b> statement, which \ |
| is the sole statement in an <b>if</b> branch. Optionally, all <b>equals</b> methods can be ignored, as contents of \ |
| <b>equals</b> is traditionally generated using early returns on type or value mismatch. |
| OPTNAME_MethodIgnoreReturnEquals=Ignore in 'equals' |
| OPTDESC_MethodIgnoreReturnEquals= |
| OPTNAME_MethodIgnoreReturnGuards=Ignore guard conditions |
| OPTDESC_MethodIgnoreReturnGuards= |
| OPTNAME_MethodReturnLimit=Return limit |
| OPTDESC_MethodReturnLimit= |
| |
| # Method with multiple negations |
| DN_MethodMultipleNegations=Method with multiple negations |
| DESC_MethodMultipleNegations=Methods with multiple negated expressions (unary <b>!</b> or <b>!=</b>) are said to confuse \ |
| readers, true (non-negated) expressions are considered easier to read and understand. Consider to change the logic to \ |
| use true instead of false values. |
| OPTNAME_MethodNegationsLimit=Negations limit |
| OPTDESC_MethodNegationsLimit= |
| OPTNAME_MethodNegationsIgnoreEquals=Ignore in equals() |
| OPTDESC_MethodNegationsIgnoreEquals= |
| OPTNAME_MethodNegationsIgnoreAsserts=Ignore in asserts |
| OPTDESC_MethodNegationsIgnoreAsserts= |
| |
| # Method with multiple loops |
| DN_MethodMultipleLoops=Method with multiple loops |
| DESC_MethodMultipleLoops=Methods that contains multiple loop statements. |
| |
| OPTNAME_MethodLoopsLimit=Maximum number of loops |
| OPTDESC_MethodLoopsLimit |
| |
| DN_MethodCoupled=Too coupled method |
| DESC_MethodCoupled=Reports methods which are too coupled - that refer to too many \ |
| other types. Methods that \ |
| refer to large number of types are <i>fragile</i>: they tend to fail or require refactoring \ |
| if the referenced type(s) change. It is also more difficult to move the method which has \ |
| many dependencies to another module. <p/>References \ |
| to the method class' itself and its superclasses are ignored. With <i>Ignore dependencies on \ |
| Java Platform</i>, references to <code>java.**</code> and <code>javax.**</code> classes \ |
| are also ignored. |
| |
| |
| # Method with many dependencies |
| OPTNAME_MethodCouplingIgnoreJava=Ignore dependencies on Java platform |
| OPTDESC_MethodCouplingIgnoreJava=Reports methods that contain too many loop statements. |
| OPTNAME_MethodCouplingLimit=Maximum coupling |
| OPTDESC_MethodCouplingLimit= |
| |
| DN_ClassTooComplex=Class is too complex |
| DESC_ClassTooComplex=Reports classes, whose cyclomatic complexity exceeds the configured limit. \ |
| The complexity of a class is computed as a sum of complexities of its methods. |
| OPTNAME_ClassComplexityLimit=Complexity limit |
| OPTDESC_ClassComplexityLimit= |
| |
| DN_ClassAnonymousTooComplex=Anonymous class is too complex |
| DESC_ClassAnonymousTooComplex=Reports anonymous classes, whose cyclomatic complexity exceeds the configured limit. \ |
| The complexity of a class is computed as a sum of complexities of its methods. Anonymous classes should have far \ |
| less responsibilities and lower complexity than a regular class |
| OPTNAME_ClassAnonymousComplexityLimit=Complexity limit |
| OPTDESC_ClassAnonymousComplexityLimit= |
| |
| DN_ClassTooCoupled=Class is too coupled |
| DESC_ClassTooCoupled=Reports classes which are too coupled (use too many) other types. References to Java system \ |
| libraries (<code>java.**</code> and <code>javax.**</code>) can be ignored. |
| OPTNAME_ClassCouplingLimit=Coupling limit |
| OPTDESC_ClassCouplingLimit= |
| OPTNAME_ClassCouplingIgnoreJava=Ignore dependencies on Java platform |
| OPTDESC_ClassCouplingIgnoreJava= |
| |
| DN_ComplexArithmeticExpression=Arithmetic expression too complex |
| DESC_ComplexArithmeticExpression=Reports arithmetic expressions, which include more than the defined number of operations. \ |
| Expression with many operands are harder to read and often could be split into several assignment statements to interim \ |
| result variables. |
| OPTNAME_ComplexArithmeticLimit=Operator limit |
| OPTDESC_ComplexArithmeticLimit= |
| |
| DN_ComplexLogicalExpression=Logical expression too complex |
| DESC_ComplexLogicalExpression=Reports logical expressions, which include more than the defined number of operations. \ |
| Expression with many operands are harder to read and often could be split into several assignment statements to interim \ |
| result variables. |
| OPTNAME_ComplexLogicalLimit=Operator limit |
| OPTDESC_ComplexLogicalLimit= |
| |
| DN_ClassConstructorCount=Class has too many constructors |
| DESC_ClassConstructorCount=Reports classes which define too many constructors. |
| |
| DN_AnonClassMethodCount=Anonymous class has too many methods |
| DESC_AnonClassMethodCount=Reports anonymous class with many methods. Anonymous classes typically implement a very simple \ |
| interface, and should be very simple. It is recommended to create at least named local class, if the anonymous \ |
| class' complexity grows. |
| |
| DN_ClassMethodCount=Class has too many methods |
| DESC_ClassMethodCount=Reports class, which contains too many methods. The options allows to ignore simple bean property \ |
| accessors - lazy getters, or setters which fire change events are not considered 'simple'. Implementations of superclass \ |
| (not implementation of interface methods) abstract methods can be also ignored. |
| |
| OPTNAME_AnonClassMethodsLimit=Methods limit |
| OPTDESC_AnonClassMethodsLimit= |
| |
| OPTNAME_ClassConstructorsLimit=Constructors limit |
| OPTDESC_ClassConstructorsLimit= |
| OPTNAME_ClassMethodsLimit=Methods limit |
| OPTDESC_ClassMethodsLimit= |
| OPTNAME_ClassFieldsLimit=Fields limit |
| OPTDESC_ClassFieldsLimit= |
| OPTNAME_ClassMethodCountIgnoreAccessors=Ignore simple accessors |
| OPTDESC_ClassMethodCountIgnoreAccessors=Does not include simple property accessors |
| OPTNAME_ClassMethodCountIgnoreAbstract=Ignore abstract method implementations |
| OPTDESC_ClassMethodCountIgnoreAbstract= |
| |
| DN_ClassFieldCount=Class has too many fields |
| DESC_ClassFieldCount=Reports a class which holds too many fields. The state kept by the class is too large and it should \ |
| be investigated if the state can be split into several state classes, often also separating manipulation methods and \ |
| reduce the overall class complexity. |
| OPTNAME_FieldCountIgnoreConstants=Ignore constants |
| OPTDESC_FieldCountIgnoreConstants= |