SiLeBAT/FSK-Lab

View on GitHub
org.hsh.bfr.db/src/org/hsh/bfr/db/MainKernel.java

Summary

Maintainability
A
3 hrs
Test Coverage

Method main has a Cognitive Complexity of 12 (exceeds 5 allowed). Consider refactoring.
Open

    public static void main(final String[] args) { // Servervariante
        isServer = true;
        if (args.length > 1) {
            if (args[1] != null) {
                dbFolder = args[1] + "/data/";
Severity: Minor
Found in org.hsh.bfr.db/src/org/hsh/bfr/db/MainKernel.java - About 1 hr to fix

Cognitive Complexity

Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.

A method's cognitive complexity is based on a few simple rules:

  • Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
  • Code is considered more complex for each "break in the linear flow of the code"
  • Code is considered more complex when "flow breaking structures are nested"

Further reading

Method main has 28 lines of code (exceeds 25 allowed). Consider refactoring.
Open

    public static void main(final String[] args) { // Servervariante
        isServer = true;
        if (args.length > 1) {
            if (args[1] != null) {
                dbFolder = args[1] + "/data/";
Severity: Minor
Found in org.hsh.bfr.db/src/org/hsh/bfr/db/MainKernel.java - About 1 hr to fix

Don't try to be smarter than the JVM, remove this call to run the garbage collector.
Open

                System.gc();

Calling System.gc() or Runtime.getRuntime().gc() is a bad idea for a simple reason: there is no way to know exactly what will be done under the hood by the JVM because the behavior will depend on its vendor, version and options:

  • Will the whole application be frozen during the call?
  • Is the -XX:DisableExplicitGC option activated?
  • Will the JVM simply ignore the call?
  • ...

Like for System.gc(), there is no reason to manually call runFinalization() to force the call of finalization methods of any objects pending finalization.

An application relying on these unpredictable methods is also unpredictable and therefore broken. The task of running the garbage collector and calling finalize() methods should be left exclusively to the JVM.

Use try-with-resources or close this "Statement" in a "finally" clause.
Open

              Statement anfrage = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);

Connections, streams, files, and other classes that implement the Closeable interface or its super-interface, AutoCloseable, needs to be closed after use. Further, that close call must be made in a finally block otherwise an exception could keep the call from being made. Preferably, when class implements AutoCloseable, resource should be created using "try-with-resources" pattern and will be closed automatically.

Failure to properly close resources will result in a resource leak which could bring first the application and then perhaps the box the application is on to their knees.

Noncompliant Code Example

private void readTheFile() throws IOException {
  Path path = Paths.get(this.fileName);
  BufferedReader reader = Files.newBufferedReader(path, this.charset);
  // ...
  reader.close();  // Noncompliant
  // ...
  Files.lines("input.txt").forEach(System.out::println); // Noncompliant: The stream needs to be closed
}

private void doSomething() {
  OutputStream stream = null;
  try {
    for (String property : propertyList) {
      stream = new FileOutputStream("myfile.txt");  // Noncompliant
      // ...
    }
  } catch (Exception e) {
    // ...
  } finally {
    stream.close();  // Multiple streams were opened. Only the last is closed.
  }
}

Compliant Solution

private void readTheFile(String fileName) throws IOException {
    Path path = Paths.get(fileName);
    try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) {
      reader.readLine();
      // ...
    }
    // ..
    try (Stream<String> input = Files.lines("input.txt"))  {
      input.forEach(System.out::println);
    }
}

private void doSomething() {
  OutputStream stream = null;
  try {
    stream = new FileOutputStream("myfile.txt");
    for (String property : propertyList) {
      // ...
    }
  } catch (Exception e) {
    // ...
  } finally {
    stream.close();
  }
}

Exceptions

Instances of the following classes are ignored by this rule because close has no effect:

  • java.io.ByteArrayOutputStream
  • java.io.ByteArrayInputStream
  • java.io.CharArrayReader
  • java.io.CharArrayWriter
  • java.io.StringReader
  • java.io.StringWriter

Java 7 introduced the try-with-resources statement, which implicitly closes Closeables. All resources opened in a try-with-resources statement are ignored by this rule.

try (BufferedReader br = new BufferedReader(new FileReader(fileName))) {
  //...
}
catch ( ... ) {
  //...
}

See

Don't try to be smarter than the JVM, remove this call to run the garbage collector.
Open

                    System.gc();

Calling System.gc() or Runtime.getRuntime().gc() is a bad idea for a simple reason: there is no way to know exactly what will be done under the hood by the JVM because the behavior will depend on its vendor, version and options:

  • Will the whole application be frozen during the call?
  • Is the -XX:DisableExplicitGC option activated?
  • Will the JVM simply ignore the call?
  • ...

Like for System.gc(), there is no reason to manually call runFinalization() to force the call of finalization methods of any objects pending finalization.

An application relying on these unpredictable methods is also unpredictable and therefore broken. The task of running the garbage collector and calling finalize() methods should be left exclusively to the JVM.

Identical blocks of code found in 2 locations. Consider refactoring.
Open

      private static Connection getDefaultConnection() {
          Connection result = null;
            String connStr = "jdbc:default:connection";
            try {
                result = DriverManager.getConnection(connStr);
Severity: Minor
Found in org.hsh.bfr.db/src/org/hsh/bfr/db/MainKernel.java and 1 other location - About 40 mins to fix
org.hsh.bfr.db/src/org/hsh/bfr/db/MyTrigger.java on lines 298..308

Duplicated Code

Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

Tuning

This issue has a mass of 51.

We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

Refactorings

Further Reading

There are no issues that match your filters.

Category
Status