Nils summarized the benefits of short methods in his post from November: These are easier to comprehend, do better document the code (by the method name), are better to reuse and simplify testing as well as debugging or profiling. As the examples were in Java, one may intend that this will work for modern languages—but not in general, and maybe not for a language like ABAP. In this post I’ll focus if short procedures (e.g., methods, function modules, or form routines) have the same relevance for ABAP or if longer procedures are to legitimate or can not be avoided.

In this blog post I will show you how to start with IntelliJ IDEA plugin development. Since there is not a lot of documentation about plugin development for IntelliJ IDEA, I’ll be explaining how to create a simple plugin and execute code after a project was opened using the StartupActivity class.

This post is about student internships at CQSE. If you are studying computer science and are looking for a job specifically designed to help you get the most out of your studies, read on.

Have you ever used static analysis tools? Then you probably know how they tend to flood you with so many analysis results findings), that you don’t know where to even start reading and resolving them. Instead of turning these tools off again, read on for some strategies for dealing with the findings flood.

As you probably know, you should keep the methods (functions, procedures, …)

in your code short and have each of them do only one thing. While hardly anyone

opposes this rule, we still find a large number of long methods in the code

bases we analyze.

Almost everybody agrees that having a consistent setup for compiler errors,

warnings and the code formatter across all team members is crucial. However,

many development projects still fail to achieve this. Surprisingly, the main

reason for this seems to be that most developers are not aware that this can be

easily enforced with Eclipse and use cumbersome »How to setup your

workspace« descriptions in the developer wiki instead. In most cases these

descriptions are outdated or generally ignored. As this is an issue that I have

repeatedly discussed with our customers (and recently at the

BITKOM Workshop in Frankfurt) I explain how

enforcing a consistent setup for compiler errors, warnings and the code

formatter works with Eclipse.

Testing is an integral part of a software product’s life-cycle. Some people prefer

executing their tests continuously while they develop, others have a separate

testing phase before each release. The goal, however, is always the same:

finding bugs. The more, the better.

Unfortunately, the time available for testing and for writing new tests is limited. At some point, you

have to get on with development, ship your software and be confident it contains

no serious flaws. Often, more tests exist than can be run in the

available time span. This is especially true if your tests are executed manually,

as is the case for many of our customers.

Then the question becomes: which tests do I select to find the

most bugs before the release?

Research has…

One of the services we offer is called Test Gap Analysis, which helps to identify changes in your code that have not been covered by your tests since the last release.

I have been working on Test Gap Analysis for the last few months and never had to worry about performance problems, until recently, when we hit a performance problem. Surprisingly, the implementation of Java's String#replace method was the culprit!

The recent blog post ‘Improving Software Quality’ by my colleague Martin showed how we can improve software quality besides just installing tools: We believe that a continuous quality control process is necessary to have a long-term, measurable impact. However, does this quality control actually have an long-term impact in practice? Or are feature and change requests still receiving more priorities than cleaning up code that was written in a hurry and under time pressure?

With our long-term partner Munich Re, we gathered enough data to show in a large-scale industry case study that quality control can improve the code quality even while the system is still under active development. Our results were accepted to be published as a conference paper at the…

Teamscale is our tool for continuous software quality control. It provides feedback about quality problems in real-time, allowing you to keep your software free of technical debt. To give you a better idea, how certain core features of Teamscale work in practice, we created a couple of short video clips that demonstrate Teamscale in action.