Using tuned.conf to disable mongod startup warnings on RHEL/CentOS 7

Timo Geusch from The Lone C++ Coder's Blog

RHEL 7 – and CentOS 7, which I used for this test – use tuned.conf to set a lot of system settings. Several of the tuned settings affect MongoDB’s performance; some are important enough that mongod actually triggers startup warnings. The main setting is transparent huge pages, which is a setting that does not work […]

The post Using tuned.conf to disable mongod startup warnings on RHEL/CentOS 7 appeared first on The Lone C++ Coder's Blog.

McCabe’s cyclomatic complexity and accounting fraud

Derek Jones from The Shape of Code

The paper in which McCabe proposed what has become known as McCabe’s cyclomatic complexity did not contain any references to source code measurements, it was a pure ego and bluster paper.

Fast forward 10 years and cyclomatic complexity, complexity metric, McCabe’s complexity…permutations of the three words+metrics… has become one of the two major magical omens of code quality/safety/reliability (Halstead’s is the other).

It’s not hard to show that McCabe’s complexity is a rather weak measure of program complexity (it’s about as useful as counting lines of code).

Just as it is possible to reduce the number of lines of code in a function (by putting all the code on one line), it’s possible to restructure existing code to reduce the value of McCabe’s complexity (which is measured for individual functions).

The value of McCabe’s complexity for the following function is 16, i.e., there are 16 possible paths through the function:

int main(void)
{
if (U) a(); else b();
if (X) c(); else d();
if (Y) e(); else f();
if (Z) g(); else h();
}

each ifelse contains two paths and there are four in series, giving 2*2*2*2 paths.

Restructuring the code, as below, removes the multiplication of paths caused by the sequence of ifelse:

void a_b(void) {if (U) a(); else b();}

void c_d(void) {if (X) c(); else d();}

void e_f(void) {if (Y) e(); else f();}

void g_h(void) {if (Z) g(); else h();}

int main(void)
{
a_b();
c_d();
e_f();
g_h();
}

reducing main‘s McCabe complexity to 1 and the four new functions each have a McCabe complexity of two.

Where has the ‘missing’ complexity gone? It now ‘exists’ in the relationship between the functions, a relationship that is not included in the McCabe complexity calculation.

The number of paths that can be traversed, by a call to main, has not changed (but the McCabe method for counting them now produces a different answer)

Various recommended practice documents suggest McCabe’s complexity as one of the metrics to consider (but don’t suggest any upper limit), while others go as far as to claim that it’s bad practice for functions to have a McCabe’s complexity above some value (e.g., 10) or that “Cyclomatic complexity may be considered a broad measure of soundness and confidence for a program“.

Consultants in the code quality/safety/security business need something to complain about, that is not too hard or expensive for the client to fix.

If a consultant suggested that you reduced the number of lines in a function by joining existing lines, to bring the count under some recommended limit, would you take them seriously?

What about, if a consultant highlighted a function that had an allegedly high McCabe’s complexity? Should what they say be taken seriously, or are they essentially encouraging developers to commit the software equivalent of accounting fraud?

Visual Lint 6.5.1.294 has been released

Products, the Universe and Everything from Products, the Universe and Everything

Visual Lint 6.5.1.294 has just been released. This is a maintenance update for Visual Lint 6.5, and is compatible with all Visual Lint 6.0 and 6.5 licence keys.

The following changes are included:

  • Built-in compiler preprocessor symbols are now automatically included in the analysis configuration for Atmel Studio projects using ARM toolchains where possible.
  • Fixed a bug which caused a "project changed" event to be erroneously sourced if an external project file located in the same folder as a loaded project was changed.
  • The PC-lint raw analysis results parser will now raise a fatal error if a PC-lint Plus License Error is detected.
  • Fixed a bug in the "Analysis Tool" Options page which affected browsing for an analysis tool installation folder.
  • Modified a handful of prompts to refer to "PC-lint or PC-lint Plus" rather than just "PC-lint".

Download Visual Lint 6.5.1.294

Visual Lint 6.5.1.294 has been released

Products, the Universe and Everything from Products, the Universe and Everything

Visual Lint 6.5.1.294 has just been released. This is a maintenance update for Visual Lint 6.5, and is compatible with all Visual Lint 6.0 and 6.5 licence keys.

The following changes are included:

  • Built-in compiler preprocessor symbols are now automatically included in the analysis configuration for Atmel Studio projects using ARM toolchains where possible.
  • Fixed a bug which caused a "project changed" event to be erroneously sourced if an external project file located in the same folder as a loaded project was changed.
  • The PC-lint raw analysis results parser will now raise a fatal error if a PC-lint Plus License Error is detected.
  • Fixed a bug in the "Analysis Tool" Options page which affected browsing for an analysis tool installation folder.
  • Modified a handful of prompts to refer to "PC-lint or PC-lint Plus" rather than just "PC-lint".

Download Visual Lint 6.5.1.294

Visual Lint 6.5.1.294 has been released

Products, the Universe and Everything from Products, the Universe and Everything

Visual Lint 6.5.1.294 has just been released. This is a maintenance update for Visual Lint 6.5, and is compatible with all Visual Lint 6.0 and 6.5 licence keys. The following changes are included:
  • Built-in compiler preprocessor symbols are now automatically included in the analysis configuration for Atmel Studio projects using ARM toolchains where possible.
  • Fixed a bug which caused a "project changed" event to be erroneously sourced if an external project file located in the same folder as a loaded project was changed.
  • The PC-lint raw analysis results parser will now raise a fatal error if a PC-lint Plus License Error is detected.
  • Fixed a bug in the "Analysis Tool" Options page which affected browsing for an analysis tool installation folder.
  • Modified a handful of prompts to refer to "PC-lint or PC-lint Plus" rather than just "PC-lint".
Download Visual Lint 6.5.1.294

Top, must-read paper on software fault analysis

Derek Jones from The Shape of Code

What is the top, must read, paper on software fault analysis?

Software Reliability: Repetitive Run Experimentation and Modeling by Phyllis Nagel and James Skrivan is my choice (it’s actually a report, rather than a paper). Not only is this report full of interesting ideas and data, but it has multiple replications. Replication of experiments in software engineering is very rare; this work was replicated by the original authors, plus Scholz, and then replicated by Janet Dunham and John Pierce, and then again by Dunham and Lauterbach!

I suspect that most readers have never heard of this work, or of Phyllis Nagel or James Skrivan (I hadn’t until I read the report). Being published is rarely enough for work to become well-known, the authors need to proactively advertise the work. Nagel, Dunham & co worked in industry and so did not have any students to promote their work and did not spend time on the academic seminar circuit. Given enough effort it’s possible for even minor work to become widely known.

The study run by Nagel and Skrivan first had three experienced developers independently implement the same specification. Each of these three implementations was then tested, multiple times. The iteration sequence was: 1) run program until fault experienced, 2) fix fault, 3) if less than five faults experienced, goto step (1). The measurements recorded were fault identity and the number of inputs processed before the fault was experienced.

This process was repeated 50 times, always starting with the original (uncorrected) implementation; the replications varied this, along with the number of inputs used.

For a fault to be experienced, there has to be a mistake in the code and the ‘right’ input values have to be processed.

How many input values need to be processed, on average, before a particular fault is experienced? Does the average number of inputs values needed for a fault experience vary between faults, and if so by how much?

The plot below (code+data) shows the numbers of inputs processed, by one of the implementations, before individual faults were experienced, over 50 runs (sorted by number of inputs):

Number of inputs processed before particular fault experienced

Different faults have different probabilities of being experienced, with fault a being experienced on almost any input and fault e occurring much less frequently (a pattern seen in the replications). There is an order of magnitude variation in the number of inputs processed before particular faults are experienced (this pattern is seen in the replications).

Faults were fixed as soon as they were experienced, so the technique for estimating the total number of distinct faults, discussed in a previous post, cannot be used.

A plot of number of faults found against number of inputs processed is another possibility. More on that another time.

Suggestions for top, must read, paper on software faults, welcome (be warned, I think that most published fault research is a waste of time).

Digg Reader shuts down, and thoughts on organising my blog reading

Timo Geusch from The Lone C++ Coder's Blog

Farewell, Digg Reader Unfortunately,  Digg announced that Digg Reader is shutting down tomorrow. While I never used Digg Reader as my main RSS feed reader – I’ve got a paid subscription to Feedly – I was very happy to use it as a backup reader for those feeds that weren’t always that great at adhering […]

The post Digg Reader shuts down, and thoughts on organising my blog reading appeared first on The Lone C++ Coder's Blog.