Checkstyle: Migrate RegexpMultiline to RegexMatchXpath

[lars-sh]

As of Checkstyle 8.39 the check MatchXpath allows us to migrate the regular expression checks to XPath.

See https://checkstyle.org/config_coding.html#MatchXpath for documentation.

[lars-sh]

TODO: Remember to check out the list of "to do and not to do" by @noxone and me some years ago. Some of those things could be tested with that.

[noxone]

The stuff from our list:

Do's

• Treat warnings as errors. Code with warnings will not be accepted.
• Write log messages using getLogger(). Log whatever you like and need using the correct log levels.

Exception handling

• Fill catch-clauses with life. Always handle your exceptions. Use the variable name ignore if you really want to suppress the exception - really rare cases only!
• Use try-with-resource as often as possible, e.g. for PreparedStatements and for ResultSets
• Exceptions must contain a message. → Custom classes extending Exception must not offer constructors without fillig the message.

Classes

• If equals() is overridden hashCode() must be overridden, too.
• Every static stuff comes at the beginning of the class - non-static code after thereafter.
• Put fields at the beginning of your code, then the constructors and the methods are the last part of a class.

Members

• Externalize configuration parameters - they do not belong into the source code
• Class members must always be private. Use getters and setters.
• Getter methods for boolean values start with is instead of get.
• Use enums where applicable - don't use integer values

Variables

• Use speaking variable names
• Remove unused variables
• Prefer Optional in favor of null

Don'ts

• Don't use System.out.println() for logging. Use getLogger() instead.
• Don't log exception messages, but log a short description and the full exceptions stack trace.

Exception handling

• Don't catch all Throwables. catch (Throwable t) is forbidden.
• Don't use new Exception(...) or new RuntimeException(...). Use or create a subclass.
• Methods must not declare throws Exception or throws Throwable
• Methods must not declare throwingRuntimeExceptions.

Statements

• Don't leave if, else, while, try, finally or switch statements empty.
• Don't set multiple members/variable in one statement.

Classes

• Don't use the classes Vector and Hashtable. Use AtomicReference, List and Map instead.
• Don't use the string constructors like new String("abc").

[lars-sh]

Great, thanks @noxone. Though I remember additional points, that I'd have expected in Confluence > Tool Tips. Will check it next Monday.

[noxone]

Do's

• Method calls for a Logger must contain a non-empty text
• Unused variables should be deleted
• use SuppressWarning as seldom as possible (warnings are errors - see above)
• Make variables final as often as possible
• Initialize variables only if the initial value makes sense at the point of code. Otherwise leave the variable uninitialized. This way the compiler can help you if you use the variable in a way that you didn't think about before.
• Use try-with-resource if possible
• Configuration parameters should not be part of your source code. Extract all configurable values.
• Fields should always be private
• getter for booleans start with is
• Too many constants with enumerated values (e.g. numbers or names) suggest the usage of an enum
• if you override equals(...) also override hashCode(...)
• Every Exception must contain a message → The constructor without parameter should not be used and your own Exceptions should not provide that constructor
• Name your variables after what you want to store in it.
• Think about the charset of your users' input. The operating system's charset might change → always explicitly specify the charset of a text.
• Always explicitly specify the charset for texts and streams. You never (!) know your user's operating systems charset.
• Use Optional.orElseThrow(...) instead of Optional.get().

Don'ts - Forbidden, Never ever

Exceptions

• Instantiation of Exceptions without a message
• throw new Exception(...) - always use specific exception classes instead
• throws Exception or throws Throwable
• except here:
• • main methods
• • abstract methods
• • methods with @OverRide
• catch (Throwable t)
• empty catch clauses
• except the exception variable is called ignore
• System.out.println(...) inside catch clauses → handle errors, throw exceptions or use a logger
• PreparedStatement or ResultSet without try-with-resource

Blocks

• methods with more than ~100 lines
• empty if, else, while, try, finally, switch statements

Variables

• variable names i, j, k, l, my* or non-english
• initializing multiple variables at once / in one line
• access static members non-static
• reuse variables for different use cases

Classes

• use of class Vector: It is outdated.
• The state-of-the-art implementation is ArrayList.
• Use Collections.synchronizedList() if you need a synchronized List.
• new String("...")
• enum.equals(...) → use == instead

[lars-sh]

Open Points:

• Use Optional.orElseThrow(...) instead of Optional.get().
• Don't: methods with more than ~100 lines
• Don't use the string constructors like new String("abc").
• Method calls for a Logger must contain a non-empty text

Exceptions

• Don't log exception messages, but log a short description and the full exceptions stack trace.
• Exceptions must contain a message. → Custom classes extending Exception must not offer constructors without fillig the message.
• Every Exception must contain a message → The constructor without parameter should not be used and your own Exceptions should not provide that constructor
• Don't: PreparedStatement or ResultSet without try-with-resource
• Allow throws Exception or throws Throwable here:
• • main methods
• • abstract methods
• • methods with @OverRide