A coding standard is a set of formally adopted guidelines, best practices, and coding conventions followed by software developers to improve the overall quality of source code.  

Static analysis is a method of software debugging where source code can be fully analyzed without executing the code. 

Barr Group Principal Engineer Dan Smith and CEO  Andrew Girson discuss coding standards and static analysis and the impact they have on the safety and security of your final product.

Related Resources

Related Courses

Transcript

Andrew Girson:  Hi, everyone.  I'm here today to talk about coding standards and static analysis.  With me is Dan Smith, Principal Engineer at Barr Group.  Dan is the creator of our Embedded Security Boot Camp training course.  He is also an international expert and knows a tremendous amount about safety and security for Embedded Software Development.  Dan, thanks for being with us.  So, when we talk about coding standards and static analysis, why are these important for embedded software developers?

Dan Smith:  Yeah, that's a, really good question.  So, let's take coding standards first.  For coding standards, there are essentially two primary reasons why an organization should adopt the coding standard. The first is to increase the readability and therefore the maintainability of the code.

Andrew:  Okay.

Dan:  So anyone who's ever had to maintain or change the software that was written by somebody else can appreciate the fact that the more consistent the code is if it's stylistically similar, if you can't tell that this code was written by this engineer versus that, it makes it much easier to understand the code and change it, without introducing bugs.

Andrew:   Sure.

Dan:   So that's, that's one reason.  The other reason for adopting a coding standard is to adhere to a certain set of prescriptive rules that dictate a certain way that the code should be written.  In other words, rules that say this is the way we recommend using this construct of the programming language.  Anyone who's used C or C++ knows that there are a lot of ways to get into trouble.

Andrew:   Right.

Dan:   So really to us, the primary reason for adopting a coding standard is to keep bugs out of the software in the first place.

Andrew:   Okay.

Dan:   So that's as far as the coding standard goes and that kind of dovetails into the concept of static analysis.  A static analysis tool can be used to enforce a coding standard.  It can do many things more than that as well which we'll talk about briefly.  But very quickly, I would just like to discuss static analysis because in my experience a lot of engineers don't even know what static analysis is.

Andrew:  Right.

Dan:   So static analysis is the analysis of a program without actually executing it.  So, for example, static analysis tool does not compile your program and execute it, it just looks at the source code and then identifies problems, but even when engineers are doing a peer code review which is another practice that we have to take.  You're essentially performing a version of Static Analysis.

Andrew:   Okay.

Dan:   Obviously these tools are best to do that.

Andrew:   Right.  Okay.  Interesting.  You know, it's obviously pretty clear to both you and me that your coding standards, static analysis, this is an important part of creating software perceived to critical devices.  One thing that really surprised, you know, we do this annual survey on safety and security.  We're in the middle of our current one right now.  And what surprised me is in 2016 when we asked about the use of coding standard and static analysis, especially on safety critical devices.  Devices where the software could kill or injure if it went bad.  It was not universal or even close to universal use of coding standard and static analysis. I mean, are people uncertain of how to use these tools?  What is the reason? What do you think the reason is for that? Why are these tools and why are coding standards not used more universally, especially for safety critical software systems?

Dan:   Yeah.  It's a good question.  And I too was very surprised by the results of the survey. Although it's fairly consistent with my consulting experience when I go in to organizations that are working on safety critical devices or even high availability systems that it's not as widespread as I would've expected.  With the coding standard, I think there are a couple things to play there.  One is that there's just inertia.  Oftentimes you have a larger code base, you have a fairly large set of engineers.  Every engineer has his or her own coding style and the whole idea of someone sitting down and writing this document and getting agreement and getting everybody to buy into it and use it, especially when the developments already underway.  It's almost too much to overcome sometimes.  So instead of just taking the hard step to do it and oftentimes it just gets deferred and eventually never gets done.

Andrew:   Okay.

Dan:   Sometimes it's also a question of awareness.  Sometimes quite honestly, people aren't aware of the idea of using a coding standard.  It's something foreign to them.  And I find this to be true more in smaller organizations where everybody's always just been able to write code in their own way.

Andrew:   They just do it their own way.

Dan:   They just do it their own way.

Andrew:   Don't worry about it.  No oversight or minimal oversight.

Dan:  That's right.  In kind of all just works and everybody kind of grumbles about the other person's coding style, but it all just kind of goes along that way.  So as far as you know why coding standards aren't used.  I think that's one of the reasons or probably two of the main reasons.  When it comes to static analysis, I also think that awareness or the opposite of that is really ignorance.  I think oftentimes there's ignorance, especially in the embedded industry.  As far as using a tool to analyze the code, everybody likes to say, "Well, my code compiles or it compiles without warnings, it's fine.

Andrew:  Right.  It works.

Dan:   It works, right? By passes the tests.  And they're not aware that there's all the stuff underneath the surface that a static analysis tool can catch that the compilers not going to catch in addition to enforcing the coding standards.  And the last thing I'd like to say about that as far as why it's not used is I also have encountered organizations that are aware of static analysis tools, but there's just too much inertia, the idea of evaluating tools, selecting a tool, configuring a tool, using a tool, getting your organization to adopt it, maybe even pushing through the purchase process that can become enough overhead where the engineer or the organization doesn't just push through it and do it.

Andrew:   You know, that that brings up a very good point.  I mean, obviously with IoT and the growing importance of software in embedded systems, devices, you know, you talk about the inertia and management and all of that.  Do you have any tips or there are any suggestions you make to the engineers and organizations who are trying to convince their management to adopt coding standards and static analysis knowing that there is going to be an implementation cost.  There is going to be an investment there, but at the end of that investment, you’ll get value.  Are there any, you know, a couple of tips or suggestions you might have for engineers who's trying to make that case to their engineering or even their business management, even their company?

Dan:  Yeah.  It's a good point.  You know, as far as cost goes, oftentimes the big hurdle isn't the cost of the tools.  It's the schedule hit which obviously--

Andrew:  Right.

Dan:   comes with a cost—the direct cost

Andrew:   The budget or--

Dan:  The budget and then shipping schedule.  And that's usually where it really comes from the pushback and really what this comes down to is this fundamental tradeoff between the short-term benefits and the long-term benefits.  And there's no question when you introduce a coding standard or perhaps even more significantly a Static Analysis tool, you will in a very short term.  So, in the initial release, you are going to see the schedule push out a little.

Andrew:   Sure.

Dan:  That's just a reality of it.  And denying, it doesn't help anybody.  The reality though is that from the very first release, you will see I'll call them medium term benefits, in other words, downstream the test organization and everything you have to do before you release that first release.  And certainly, subsequent releases as well as the life of that software when it’s deployed in the field.  You're going to actually reap the benefits.  In other words, fewer warranty claims, fewer hits to your reputation because of problems.  God forbid and actual recall or something like that or the worst case scenario a lawsuit--

Andrew:   Right.

Dan:   -- because of damage or injury.  So, it's always this tension, this tradeoff between the short term benefits can we afford to do it versus knowing deep down, that's the long term benefits are there and when are we willing to actually make that commitment and that's really where it comes down to.

Andrew:   Sounds good.  I'm going to be interested to see in this year's survey whether we start to get an improvement in the number of people, the percentage of engineers that are using Coding Standards and Static Analysis.  I certainly hope that's the case.  Thanks a lot, Dan.  This was great.

So, I hope you enjoyed this.  We're going to go-- We're going to do a Part 2 on this soon where we talk about conforming to coding standards such as, MISRA and the difficulty with doing so.  Thank you.