There are so many rules in PMD. One can get overwhelmed by the rules and can be unsure of which rules to give priority to. PMD fortunately gives priority to each of the rules that it define. But it does not elaborate on why the priority. This post has tried re-prioritize the rules and has given reasons as to why the particular priority for the rule. It has not covered certain sections which which the author is not familiar or considers to be not used much in the industry. Hope it helps. Please do provide your feedback on the new priorities and put in your priorities if you have a different one with reasons.
The goal of setting the priority in this fashion is to make the code simpler, avoid bugs and pay attention to performance.
The goal of setting the priority in this fashion is to make the code simpler, avoid bugs and pay attention to performance.
Priority
|
Meaning
|
1
|
Must follow
|
2
|
May indicate problems which can lead to instability or performance
issues
|
3
|
Impacts Readability
|
4
|
Redundant Code
|
Rule
|
Priority
|
Default Priority
|
Reasoning
|
1
|
It is very important to carry out the copy paste checks and
eliminate duplication of code. This will lead to cleaner and better
maintainable code. This will also eliminate lot of errors when the code is
changed for fixing a bug or for enhancing the application.
|
||
1
|
3
|
Presence of Empty catch blocks indicates poor exception handling
and this can lead to unforeseen program crashes
|
|
4
|
3
|
It will not impact the program in any way and can be safely
ignored.
|
|
2
|
3
|
While it may look similar to the EmptyIfStmt we may end up with
infinite loops and so this must be included
|
|
3
|
3
|
It will not impact the program in any way and can be safely
ignored.
|
|
2
|
3
|
Empty finally blocks may indicate that the resources are not
being closed ; and not closing resources will lead to applications not
performing well. So this needs to be addressed at least a second priority
|
|
3
|
3
|
It will not impact the program in any way and can be safely
ignored.
|
|
2
|
3
|
It is better to check for these upfront as this would in most
scenarios be a bug. It is very rare scenarios where this situation would be
genuine.
|
|
3
|
3
|
This only reduces the readability. It will not impact the
functionality of the program.
|
|
3
|
3
|
This does not impact the stability of the program, it can cause
performance problems if this is present in a frequently executed method.
|
|
1
|
3
|
This can cause unforeseen problems in the system and this error
should not be ignored. This is not something that is understood by many and
it makes sense to include this check.
|
|
1
|
1
|
This can cause problems in highly active systems. It is better to be prepared for such a
situation rather than assuming that it will not happen.
|
|
1
|
3
|
It is better to check for such scenarios and eliminate them
rather than wait for situations to occur where this is exercised and we face
a surprise.
|
|
3
|
3
|
This will not create a problem or instability in the system, but
in systems where performance is key we should not ignore this as this can
cause sufficient delays in the code execution. It will take a higher priority
in applications where latency matters.
|
|
4
|
3
|
It will not impact the program in any way and can be safely
ignored.
|
|
4
|
3
|
It will not impact the program in any way and can be safely ignored.
|
|
3
|
3
|
It is difficult to maintain code where this is used as a
principle. If there are few occurrences it may be OK, but too many of these
can cause a maintainability issue. This was old style of commenting out
unwanted code when one was unsure of deleting it.
|
|
3
|
3
|
Should not normally cause a problem in the execution logic so
this need not be given very high priority.
|
|
2
|
2
|
This should be eliminated as this can cause GC problems especially
in applications where the occurrences are high.
|
|
4
|
3
|
It will not impact the program in any way and can be safely
ignored.
|
|
3
|
3
|
These do not impact the performance or the functioning of the
program in any significant way and can be given lower priority
|
|
3
|
3
|
These do not impact the performance or the functioning of the
program in any significant way and can be given lower priority
|
|
2
|
3
|
It is better to follow this rule to eliminate any class cast
exceptions and it also makes a code a little more efficient.
|
|
1
|
3
|
This should be followed if one is particular about precision.
Usage of numbers instead of strings in the constructor can lead to problems
normally associated with doubles and floats.
|
|
1
|
3
|
These can potentially have come about because of the
misunderstanding of the developer. It is better to check for these problems and
solve them.
|
|
1
|
3
|
These are bugs and this rule will prevent these bugs.
|
|
1
|
3
|
This can detect possible NullPointerExceptions. It is better to
keep this Rule on
|
|
1
|
3
|
This check should be on so that one does not end up making the
mistake of using ThreadGroups which is not a thread safe object.
|
|
1
|
2
|
This can detect possible NullPointerExceptions. It is better to
keep this Rule on
|
|
2
|
3
|
One can give this a lower priority to this as it does not impact
the stability in a big way. It can cause memory problems so it is better to
look at it. It needs to be given a higher priority where BigIntegers are used
in a big way.
|
|
1
|
3
|
Usage of octal values is no longer a normal practice and it is
likely that the person has used it erroneously. It is better to check for
this upfront rather than delay it.
|
|
1
|
3
|
Although in the strictest of sense it does not impact the
application in any way it is better to address this upfront as one is bound
to have problems going forward.
|
|
1
|
3
|
It is better to do this as one can end up in situations where
the application will fail because this check is not done.
|
|
1
|
2
|
This in theory does not cause a problem in the system if written
correctly, but it will be very few developers who can write this code
correctly and understand it correctly. So in most cases it would be an error.
It is better to eliminate them right at the start.
|
|
4
|
3
|
It will not impact the program in any way and can be safely
ignored.
|
|
2
|
3
|
This in theory does not cause a problem in the system but it is
better to enforce this and get the developers habituated to using braces for
all cases.
|
|
2
|
3
|
This in theory does not cause a problem in the system but it is
better to enforce this and get the developers habituated to using braces for
all cases.
|
|
2
|
3
|
This in theory does not cause a problem in the system but it is
better to enforce this and get the developers habituated to using braces for
all cases.
|
|
2
|
3
|
This in theory does not cause a problem in the system but it is
better to enforce this and get the developers habituated to using braces for
all cases.
|
|
2
|
2
|
Be sure of what and how one should to clone. Otherwise one can
end up with surprises. Cloning is not understood by all and improper
implementation can lead to situations where values are changed without one’s
knowledge. It will also be difficult to trace out the problem as things can
change from any one instance of cloned object.
|
|
2
|
3
|
Must follow convention.
|
|
2
|
3
|
Must follow convention.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
complex. The default of 200 paths is reasonable.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
complex. The default of 100 lines of code is reasonable.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become complex.
The default of 10 parameters is reasonable.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
complex. The default of 1000 lines of code is reasonable.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
complex. The default of 10 decision points is reasonable.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
complex. The default of 45 public may be less if one considers an Object Relational
Mapping environment. One could possibly increase this to 100 to get a
reasonable assessment.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
complex. The default of 15 fields may be less if one considers an Object Relational
Mapping environment. One could possibly increase this to 50 to get a
reasonable assessment.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
complex. The default of 100 lines of code is reasonable.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
complex. The default of 1500 lines of code is reasonable.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
complex. The default of 100 lines of code can be further reduced to 50 as
number of lines of code in constructors should ideally be as small as
possible.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
complex. The default of 10 methods seems to be on the lesser side. One should
consider increasing this to about 120 considering the getters and settings
that one would end up writing.
|
|
3
|
3
|
This will not cause any problem to the stability of the
applications can be safely given a lower priority
|
|
2
|
3
|
Although this looks like an innocuous problem, it can indicate
lack of knowledge of the developer. It is better to eliminate them.
|
|
3
|
3
|
This is definitely a controversial rule. One is seeing trends of
moving away from this rule which was quite popular when C/C++ ruled roost. It
is better to give this a lower priority considering that it does not cause
any stability issues.
|
|
4
|
3
|
This does not cause any problem and sometimes can add to the understanding
of the program for a junior programmer. It is better to give this a very low
priority.
|
|
1
|
3
|
The usage of such a syntax can cause confusion and can also be
in error unless on is very sure of what is doing. It is better to eliminate
these upfront
|
|
4
|
3
|
This is definitely another controversial rule. We can ignore
this rule safely without having any problems.
|
|
2
|
4
|
It is better to implement this rule and not let the junior
programmers cause problems by importing these packages.
|
|
1
|
3
|
Usage of octal values is no longer a normal practice and it is
likely that the person has used it erroneously. It is better to check for this upfront rather
than delay it.
|
|
2
|
3
|
This is a useful rule to have to avoid making mistakes which can
go undetected. It should be given a higher priority in applications which use
inheritance in a big way.
|
|
3
|
3
|
It does not harm the application, but can confuse the reader.
|
|
2
|
3
|
It is better not to have any classes in the default package.
|
|
3
|
3
|
It does not impact the functionality of the programs but can
cause performance issues. So it can be given a lower priority unless it is
used in too many places.
|
|
3
|
5
|
These can be given lower priority as the ones not detected by
compiler are harmless.
|
|
3
|
3
|
Does not cause any problem, but makes sense to eliminate them
with a lower priority
|
|
1
|
1
|
Better to include this and totally eliminate usage of Short
variables.
|
|
1
|
2
|
Very few people understand the exact working of volatile
variables especially since the definition/interpretation has changed over
different versions of JDK. It is better to discourage usage of this keyword.
When used it should used under the supervision of somebody who understands
the implications.
|
|
2
|
2
|
In some cases usage of native code is unavoidable. Where
required it should be used with precaution.
|
|
1
|
3
|
This definitely must not be attempted. It is better to stay away
from this.
|
|
2
|
2
|
Although one can render this call redundant by passing the right
parameters to the JVM at startup, it is better to discourage usage of this.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
tightly coupled. The default of 20 distinct objects is fine.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
tightly coupled. The default of 30 distinct objects is fine.
|
|
1
|
3
|
Usage of this rule will ensure that the programs do not become
tightly coupled. It is very important to follow this rule.
|
|
4
|
3
|
This is not really necessary. Instead create all methods as
static and have a private constructor to avoid the warning. Do not make a
singleton. Creation of a singleton object is error prone and the syntax of
invocation of these methods because longer as in
|
|
3
|
3
|
This may not may not be a good idea depending on the developer
levels. It can be given lower
priority. It will not impact the performance or stability of the code.
|
|
2
|
3
|
This does not cause any functionality problem, application of
this rule will push the users towards naming the methods correctly.
|
|
2
|
3
|
This is a good to have rule. There can be situations where one
may not need a default label for the switch statement.
|
|
1
|
3
|
It is better to discourage developers from building deeply
nested ifs and causing readability problems. It will force them to learn to
create functions. The default value of 3 is fine.
|
|
3
|
2
|
This is usually safe in most scenarios and hence can be given a
lower priority.
|
|
1
|
3
|
Implementation of this rule will improve the readability of the
code and will force creation of smaller functions/methods. The default value
of 10 is fine.
|
|
1
|
1
|
This check must be made as it can cause errors which will be
difficult for the developers to identify.
|
|
2
|
3
|
It is better to avoid inner classes unless really essential.
This rule can lead to elimination of inner classes.
|
|
2
|
3
|
In most cases final fields should be static. It is better to
have this rule one and save some memory.
|
|
1
|
3
|
Extremely important and must be included. The opened resources
have to be closed.
|
|
1
|
3
|
Good to avoid. These are not features understood by many and so
should not be used by many. J
|
|
1
|
3
|
Good to avoid. These are not features understood by many and so
should not be used by many. J
|
|
1
|
3
|
Good to avoid. These are not features understood by many and so
should not be used by many. J
|
|
1
|
3
|
This must be used as it will bring some efficiency.
|
|
1
|
3
|
One should not be in a situation where one has to check for NaN.
|
|
1
|
1
|
This is again a bug and this rule should be enabled to avoid
this problem.
|
|
1
|
3
|
Although ternary operator works as efficiently as other
mechanisms they are not the easiest to understand. It is better to completely
avoid usage of this operator.
|
|
2
|
4
|
This will reduce creation of objects.
|
|
2
|
3
|
We should use this rule to eliminate bad, redundant code.
|
|
1
|
3
|
It is good to follow this rule to prevent any surprises in date
formatting.
|
|
2
|
3
|
This does not add much value as many do not understand immutable
classes. This can be given a lower priority.
|
|
1
|
3
|
This is important in applications that are to be
internationalized. Most developers do not understand internationalization. It
is better to include this rule to avoid surprises.
|
|
4
|
3
|
This does not cause any problem. It is better to give this a
very low priority.
|
|
2
|
3
|
This can create hidden bugs, especially in a multi-threaded
application. It is better to identify these upfront and not let the situation
occur
|
|
3
|
3
|
These classes end up being redundant classes. These will not
cause too much problem and can be given a lower priority.
|
|
1
|
3
|
Synchronizing the method causes major performance issues in the
system. It is good to void synchronizing methods. Instead one should
synchronize with “this” wherever required.
|
|
1
|
3
|
In most scenarios a missing break indicates an error. In cases
where this is valid it is better to pull out the logic to a function and
invoke this function from the case blocks where required.
|
|
1
|
3
|
These are aspects not understood by many. It is better to catch
these problems upfront.
|
|
1
|
3
|
Usage of this indicates improper exception handling. It is good
to force developers to learn good exception handling practices by usage of
this rule.
|
|
1
|
3
|
This situation should not exist. If it does it shows lack of
knowledge on part of the developer.
|
|
1
|
3
|
This is again something not known to everybody and this rule
needs to be in place for eliminating such problems.
|
|
1
|
3
|
This in most cases is a bug. It is good to have this rule turned
on.
|
|
1
|
3
|
This is a good rule to follow to avoid NullPointerExceptions.
Enforcing of this will make the developers follow this good practice.
|
|
4
|
3
|
This does not cause any problem and sometimes can add to the
understanding of the program for a junior programmer. It is better to give
this a very low priority.
|
|
1
|
3
|
Extremely important. Not many understand and the rule will go a
long way towards eliminating lot of surprises.
|
|
4
|
3
|
This does not cause any problem. It is better to give this a
very low priority.
|
|
4
|
3
|
This does not cause any problem. It is better to give this a
very low priority.
|
|
2
|
3
|
It is good to define the constants in the right places. Defining
an interface for only the constants is not a right approach and should be
avoided.
|
|
1
|
3
|
This is not known to many and it is better to have this check in
place to avoid surprises.
|
|
1
|
3
|
Extremely important as it leads to a good Exception handling framework.
|
|
2
|
3
|
The performance impact is not known to many. It is good to have
this rule in place.
|
|
2
|
1
|
A good rule to have. Will not be a disaster if we do not give it
a very high priority.
|
|
1
|
1
|
It is important not to have empty implementations of Abstract
methods as the sub-classes may not override this method thinking there is an
implementation in the super class.
|
|
1
|
3
|
This rule can prevent creeping of bugs. If the value of the
variable needs to be set it should be done through a set method rather than
through a generic method.
|
|
2
|
1
|
This helps preventing Null Pointer Exceptions and it makes sense
in having this check given higher priority.
|
|
1
|
1
|
It does not make sense to have such a class and it is better
that such classes are dropped or converted to interfaces if required.
|
|
1
|
1
|
It is better to use an if - else if statement instead of switch
statements in these scenarios.
|
|
3
|
3
|
Makes no sense in having an empty finalizer. Becomes important
in an application dealing with JNI. Otherwise this can be given a lower
priority.
|
|
3
|
3
|
Makes no sense in having an empty finalizer. Becomes important
in an application dealing with JNI. Otherwise this can be given a lower
priority.
|
|
2
|
3
|
Not many understand the finalize function and this rule can
prevent users from creating this method inadvertently.
|
|
1
|
3
|
If finalize is being used then it s important to invoke
super.finailize() as one needs to ensure that all the native resources are
properly cleaned up.
|
|
1
|
3
|
If finalize exists it is must to have this as protected so that
it is not possible to invoke this from outside.
|
|
1
|
3
|
Even if finalize were visible one should not invoke this.
|
|
2
|
4
|
It is good to eliminate duplicate imports. This rule should be
implemented.
|
|
2
|
4
|
Objects and packages from Java.lang should never be downloaed.
|
|
2
|
4
|
Unused imports should be eliminated. The IDEs have the feature
to remove these at the stroke of a key. It is better to keep this rule and
eliminate duplicates.
|
|
2
|
3
|
This is unecessary import and should be eliminated.
|
|
2
|
3
|
Too many static imports can cause confusion. Instead one should look
at moving these static fields to this class if this is the class where it is
being used the most.
|
|
3
|
This can be important for applications which serialize beans for a long term. As the versions change if this is not set properly this will lead to problems in the application.
|
||
3
|
|||
3
|
|||
3
|
|||
3
|
|||
3
|
|||
3
|
|||
3
|
|||
3
|
|||
3
|
|||
3
|
|||
3
|
|||
1
|
3
|
This is important otherwise tracking the root cause can become
difficult.
|
|
1
|
3
|
This is important otherwise one can end up with unforeseen
messages in the logs.
|
|
1
|
2
|
We should not have more than one type of logger in a system.
|
|
1
|
2
|
It should be for efficiency as one will need to instantiate this
only once per object.
|
|
1
|
2
|
System.out.println should be discouraged. One should instead use
logging in a sensible fashion even for debugging.
|
|
1
|
3
|
One should not do printStackTrace. One should get it through a
logger if required.
|
|
1
|
3
|
It is important to use List instead of Vectors because we will
be decoupling the application from the underlying implementation of the
Collection
|
|
1
|
3
|
It is important to use Map instead of HashTables or HashMaps
because we will be decoupling the application from the underlying
implementation of the Collection
|
|
1
|
3
|
It is better to use this as this is the new method of iterating
through a list which cannot be accessed via an index.
|
|
1
|
2
|
Enum has become a keyword and hence it should not be used as a
variable name.
|
|
1
|
2
|
Assert has become a keyword and hence it should not be used as a
variable name.
|
|
1
|
2
|
Use the predefined Integers wherever possible to reduce creating
of unnecessary objects.
|
|
1
|
2
|
This helps improving memory usage and so should be implemented.
|
|
1
|
2
|
This helps improving memory usage and so should be implemented.
|
|
1
|
2
|
This helps improving memory usage and so should be implemented.
|
|
3
|
|||
3
|
|||
3
|
|||
3
|
|||
3
|
|||
1
|
3
|
Extremely small variable names should be discouraged. It will
lead to unmaintainable code. The default value of less than 3 characters is
fine.
|
|
1
|
3
|
Extremely long variable names can cuase problem. The default
value of 17 may be small and we may look at increasing this to 30.
|
|
1
|
3
|
Very short method names will be a problem and need to considered
for reporting.
|
|
1
|
1
|
These bare minimum rules should be followed by all developers
with regards to naming convention.
|
|
1
|
1
|
These bare minimum rules should be followed by all developers
with regards to naming convention.
|
|
1
|
1
|
These bare minimum rules should be followed by all developers
with regards to naming convention.
|
|
1
|
3
|
These bare minimum rules should be followed by all developers
with regards to naming convention. It helps if one is able to identify the
Abstract classes by just looking at their name. It may make sense to add a
rule to have interfaces prefixed with I so that to identify them just as
easily.
|
|
2
|
3
|
Using the $ symbol in variables names is not a common practice
and it is better to discourage the usage.
|
|
1
|
3
|
Only constructors should have same name as the class. The
methods must have different names.
|
|
2
|
3
|
HashCode method should be implemented if and only if required.
Existence of a misnamed Hashcode method can cause confusion.
|
|
2
|
3
|
It is better to have the constants fields properly name and
distinguished from the attributes of the class.
|
|
2
|
2
|
If a equals method is written it should be written properly. An
improper equals method will cause confusion.
|
|
1
|
3
|
Only constructors should have same name as the class. The
fields/attributes must have different names.
|
|
1
|
3
|
Keep method and attribute names distinct. It can lead to
confusion and errors if not followed properly.
|
|
1
|
3
|
Every class should be in a package.
|
|
1
|
3
|
The case of the package should be all small cases.
|
|
2
|
3
|
Normally m_ is used to indicate the attribute of a class. Usage
of this convention for other types of variables can cause a problem. It is
better to avoid this.
|
|
2
|
4
|
Instead of get method for returning Booleans one should consider
using a isAttribute method.
|
|
2
|
3
|
This could be taken with slightly lesser priority. Not doing
this will normally not cause a problem.
|
|
2
|
3
|
This could be taken with slightly lesser priority. Not doing
this will normally not cause a problem.
|
|
3
|
3
|
This is a good practice, but many a times this is a requirement
and has to be violated.
|
|
1
|
3
|
Improves performance and so this rule should be enabled and
followed.
|
|
1
|
3
|
Give a performance gain and should be used.
|
|
1
|
3
|
Absolutely important to have this rule enabled. Consider using
StringBuilder in cases where the code is going to be executed only inside a
single thread.
|
|
1
|
3
|
Important for getting good performance.
|
|
1
|
3
|
Important for getting good performance.
|
|
2
|
3
|
Important from a good memory management perspective.
|
|
1
|
3
|
Important to follow this rule as string concatenation is bad in
Java.
|
|
5
|
|||
1
|
3
|
It covers too many of errors and one should try to handle
specific exceptions instead of a generic exception.
|
|
1
|
3
|
One should throw specific exceptions rather than a generic one
so that one is in control rather than at the mercy of the underlying code.
|
|
1
|
3
|
Definitely a must. Presence of this error indicates improper
understanding or implementation of Exception Handling.
|
|
1
|
3
|
One should not catch NullPointerExceptions. If at all it should
be handled only at the topmost level.
|
|
1
|
1
|
Throw specific Exceptions to the extent possible.
|
|
1
|
1
|
Null Pointer Exception should never be thrown. It should be left
as an unhandled exception at all levels except at the entry points into the
system.
|
|
3
|
3
|
No sense in doing it, but at least it is being rethrown instead
of being suppressed which is even worse.
|
|
1
|
3
|
Improper Exception handling.
|
|
1
|
4
|
One should not throw an Exception in the finally block as one
will not know if a real exception has happened elsewhere. It will become
extremely difficult to trace the root cause.
|
|
3
|
3
|
No sense in doing it, but at least it is being rethrown instead
of being suppressed which is even worse.
|
|
1
|
3
|
Use a constant. The compiler does try to address these issues,
but it is better for us to address it rather than depending on the compiler
to do it for us.
|
|
4
|
2
|
Harmless. Does not add to the problems
|
|
3
|
3
|
Better to avoid to bring some efficiency into the execution.
|
|
1
|
3
|
Will reduce the improvement brought about by the usage of
StringBuffer or StringBuilder.
|
|
2
|
3
|
Use equalsIgnoreCase instead of converting the strings toUpper
or toLower for comparison
|
|
1
|
3
|
Use the stringBuffer.length instead of
StringBuffer().toString().length(). It will unnecessarily create a string
before the length is determined.
|
|
1
|
3
|
Do this to get better performance.
|
|
1
|
3
|
Will reduce the improvement brought about by the usage of
StringBuffer or StringBuilder.
|
|
1
|
3
|
Use this to get better performance
|
|
1
|
3
|
Use a utility function to improve performance
|
|
1
|
3
|
If possible specify an initial buffer length for the
StringBuffer and if possible also a growth rate to get better performance.
|
|
1
|
3
|
Good practice.
|
|
1
|
4
|
This is extremely dangerous and is actually a bug.
|
|
1
|
3
|
Not using equals will lead to bugs.
|
|
1
|
3
|
This can lead to memory leaks and these can be difficult to
spot. It is better to have this check in place to avoid this problem.
|
|
1
|
3
|
It is not good to expose the variable in a class to the external
world. Copy and return the array to avoid surprises. One the array goes out of the class one cannot predict on how the values can change in the external world and all these changes will be reflected back in the array in the class and similarly any changes to the array in the class will be reflected in the outside world and one would not know how the rest of the world will react to those changes.
|
|
1
|
3
|
Do not have reference to external variables. Instead create a copy
and keep it to avoid surprises. Like above it is again risky to just keep a reference to an array passed from the external world as it can change outside the class and one cannot predict how the system will react to these changes.
|
|
1
|
3
|
Need to have this to avoid tight coupling to specific classes
|
|
3
|
3
|
||
2
|
4
|
Avoid having unused imports.
|
|
1
|
3
|
Throw specific exceptions instead of generic exception
|
|
3
|
3
|
It is better to eliminate unused codes as it reduces the
footprint of the objects when loaded in memory.
|
|
3
|
3
|
It is better to eliminate unused codes as it reduces the
footprint of the objects when loaded in memory.
|
|
3
|
3
|
It is better to eliminate unused codes as it reduces the
footprint of the objects when loaded in memory.
|
|
3
|
3
|
It is better to eliminate unused codes as it reduces the
footprint of the objects when loaded in memory.
|
|
2
|
3
|
Avoid using class loader unless you are very sure of what you
are doing.
|
|
3
|
4
|
It is good to follow a standard naming convention so that everybody
can understand what is happening.
|
|
3
|
4
|
It is good to follow a standard naming convention so that
everybody can understand what is happening.
|
|
3
|
4
|
It is good to follow a standard naming convention so that
everybody can understand what is happening.
|
|
3
|
4
|
It is good to follow a standard naming convention so that
everybody can understand what is happening.
|
|
3
|
4
|
It is good to follow a standard naming convention so that
everybody can understand what is happening.
|
|
1
|
3
|
System.exit should not invoked within a J2EE application as this
will cause the entire JVM to halt. This should be invoked only by the
container.
|
|
1
|
3
|
Violation of this rule can lead to surprising results.
|
|
2
|
3
|
This is a good practice, but there can be situations where this
needs to be violated. But one should be very careful if one violates this.
|
|
3
|
|||
2
|
|||
3
|
|||
3
|
|||
2
|
|||
3
|
|||
2
|
|||
2
|
|||
3
|
|||
3
|
|||
3
|
|||
3
|
|||
3
|
|||
3
|
No comments:
Post a Comment