The HelpSyntaxHelper had suppressed warnings for string concatenation within StringBuilder - the point of the StringBuilder is that it is faster when you use it to concatenate many elements. If you still use string concatenation with + within these calls it beats the purpose.
Had to create a getter for the Management instance in the AuthMe class for mocking, but fields should generally not be accessed globally. Hopefully soon we will be able to make the field private.
Minor refactorings in the command section for familiarization.
1. Removed suppressWarning("Deprecated") - the method is deprecated for a reason and we should be made aware of that.
2. Removed same javadoc on ExecutableCommand implementation that just had the same as the interface (this is just clutter; @Override signals that it's an implementing class and a developer can view the superclass javadoc)
3. In places where the AuthMe instance was retrieved at the top but used at the very bottom, moved it to the bottom to reduce its "scope"
The HelpSyntaxHelper had suppressed warnings for string concatenation within StringBuilder - the point of the StringBuilder is that it is faster when you use it to concatenate many elements. If you still use string concatenation with + within these calls it beats the purpose.
(cherry picked from commit bb00be2)
Had to create a getter for the Management instance in the AuthMe class for mocking, but fields should generally not be accessed globally. Hopefully soon we will be able to make the field private.
(cherry picked from commit f1a0022)
Minor refactorings in the command section for familiarization.
1. Removed suppressWarning("Deprecated") - the method is deprecated for a reason and we should be made aware of that.
2. Removed same javadoc on ExecutableCommand implementation that just had the same as the interface (this is just clutter; @Override signals that it's an implementing class and a developer can view the superclass javadoc)
3. In places where the AuthMe instance was retrieved at the top but used at the very bottom, moved it to the bottom to reduce its "scope"
(cherry picked from commit 45a50f3)
Ideally JavaDoc should provide additional information to the developer
as to the method's purpose and usage. Typically you do not add the
return type of the method and the parameter's types since this can be
seen in the code.
A short description of what the parameter really is (e.g. a String can
hold many types of information) is a lot more beneficial. A JavaDoc
statement simply restating the parameter types and the method name is,
put bluntly, simply noise, since all of these things are already
contained in the code itself.
Similarly, @see references are great for pointing to other, related
methods but aren't very helpful to point to a superclass method (the
implemented or overriden method) since it is implied by @Override. A
developer can navigate easily to the superclass method with any
reasonable IDE.
Note that the new dependencies in the pom have the scope set to test, so
they will not be included into the built artifact. A first test class
illustrates the general way unit tests can be set up with JUnit, Mockito
and Hamcrest matchers.
