Abstract: Unlock the power of HIS metrics in Understand and ensure your code is robust, maintainable, and bug-free with this comprehensive guide to utilizing these essential code quality measures.
Introduction
Okay, picture this: you’re staring at a massive codebase, feeling a bit like you’re lost in a dense jungle. Bugs are lurking like predators in the undergrowth, and you’re not even sure which direction to head in. That’s where HIS metrics come in. They act as your trusty machete, helping you hack through the tangled mess of code, and your compass, guiding you towards cleaner, more maintainable software.
These metrics give you a detailed map of your code’s health, highlighting potential problem areas like overgrown complexity, bloated functions, or tangled dependencies. They’re like a comprehensive checkup, measuring things like how easily your code can be understood, how likely it is to break, and how much effort it’ll take to make changes down the road. By keeping an eye on these vital signs, you can catch those nasty bugs before they bite, and build software that’s not just functional, but also robust, reliable, and ready for the future.
What are HIS Metrics?
HIS metrics (Hersteller Initiative Software) are a set of software quality metrics initially developed by a group of German automotive manufacturers (Audi, BMW Group, DaimlerChrysler, Porsche, and Volkswagen). They were designed to standardize code quality measurement and ensure the development of high-quality, maintainable code for automotive systems. (https://emenda.com/his/)
Why are HIS metrics important?
- Improved Code Quality: HIS metrics help identify potential issues in your code, such as high complexity or poor readability, which can lead to bugs and maintenance challenges.
- Reduced Development Costs: By addressing code quality early on, you can reduce the time and resources spent on debugging and maintenance later in the development lifecycle.
- Enhanced Maintainability: Code that adheres to HIS metrics is generally easier to understand, modify, and enhance, making it more maintainable over time.
- Increased Reliability: Well-structured, easily understandable code is less prone to errors, resulting in more reliable software.
- Compliance with Standards: In some industries, particularly automotive, adhering to HIS metrics may be necessary to comply with safety standards like ISO 26262.
How do I access HIS Metrics in Understand?
My goal with this project was to improve HIS access in Understand. Initially, I must confess to being misled by the name itself: “HIS Metrics”. The word “Metrics” made me think these were something I could find in the metric browser. However, “HIS Metrics” are actually CodeChecks in Understand, probably because they have thresholds that can be checked for. It also turns out that there’s a python script that can export HIS Metrics as a CSV described here.
The Problematic HIS Metric
So maybe accessing HIS metrics isn’t intuitive to me, but it’s still there. Does anything really need to change? Well, the NOMV metric, defined as the Number of MISRA HIS Subset violations, wasn’t supported. It isn’t possible to run CodeCheck to find MISRA violations from inside a running CodeCheck check since it’s circular. However, a metric can depend on violations, like the CodeCheck metric plugins. And, yes, I’m still stuck on why something with “Metric” in the title isn’t a metric so I’m going to change it.
New! HIS Metrics as Real Metrics
It turns out that several of the HIS Metrics are built-in Understand metrics already:
- PATH – CountPath
- v(G) – Cyclomatic
- STMT – CountStmt
- SCHG – CountLineChanged
- SDEL – CountLineRemoved
- SNEW – CountLineNew
The remaining metrics have been added as metric plugins with the following IDs:
- COMF – RatioCommentsWithBeforeToCode
- GOTO – CountGoTo. Note that the implementation for the metric differs from the implementation of the check.
- CALLING – CountCallbyUnique
- CALLS – CountCallsUnique
- PARAM – CountParams
- LEVEL – MaxCallDepth. This will be -1 if there are cycles/recursion
- RETURN – CountEarlyExit. Note that the check was only counting early exists, not return statements at the end of the function. So, the corresponding metric is CountEarlyExit with a threshold of 0. Also, the metric implementation differs from the check implementation.
- VOCF – LanguageScope
- AP_CG_CYCLE – MinRecursiveDepth. Note the check only determined if a function was recursive or not, so the metric is 0 if not recursive or the call level at which it becomes recursive.
- S – StabilityIndex. Note that metric implementation differs from the check implementation and that both use lines rather than statements.
- NOMV – HISNOMV. The metric accesses results of CodeCheck that are running in the background so the HIS MISRA Subset must be configured to run in the background.
New! HIS Metrics Interactive Report
New metrics are nice, but now do I have to memorize this mapping of HIS Metric acronyms to Understand metric IDs? Of course not. There’s an ireport! Think of the ireport as a prettier and more interactive version of the csv export script.
Turn it on from the plugin manager (Tools->Plugins):
Then select a class, file, or architecture and view the HIS metrics for each function. Or run it for an entire project from Project->Interactive Reports. Metrics are visible both in summary charts and in an exportable table. Select a function and view the metrics for just that function.
Conclusion
HIS Metrics have been available in Understand for a long time, but new plugins make them more accessible than ever before. All the plugins are part of our public plugin repository, making them easy to customize. Or request custom scripts. Understand isn’t just another IDE, it can be your platform for getting your information, your way.
