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.  

Barr Group Principal Engineer Dan Smith and CEO Andrew Girson discuss problems that can arise when migrating to a coding standard, and things your team can do to ease the transition.

Related Resources

Related Courses

Transcript

Andrew Girson:  Hi, everyone. Welcome back. We're here for part 2 of our discussion on embedded software Coding Standards and Static Analysis. In part 1, we discussed the importance of Coding Standards and Static Analysis. What those tools are? How to use them and the value in them?

Now we're gonna talk a little bit more about conforming to Coding Standards and some of the issues we're trying to make your code, conform the coding standards, the things that you'll deal with there. I'm joined again by Dan Smith. Dan, thanks for coming back. Dan is the,as I noted before, the Creator of our Embedded Security Boot Camp training course. He's a well-known expert on safety and security and embedded systems and embedded software and Dan is an expert on the use of Coding Standards and Static Analysis.

So, Dan, I often get engineers who come to us understand the value Coding Standards, but they're not really sure how to start or to choose a Coding Standard. Can you offer any suggestions to them on how to start, how to choose a Coding Standard?

Dan Smith:  Yeah. Sure. So, you know, one thing I've heard is that the most frightening thing to an author is staring at a blank page.

Andrew:  Right.

Dan:  And I think that it's the same thing with a Coding Standard. If somebody, if an engineer who really wants to lead the charge up the hill and then introduce a Coding Standard, if he or she is just sitting there and, you know, and with a blank sheet like where do I start typing, how do I do this, what's the structure of the document? It's very overwhelming.

So, we often recommend is start with an existing standard or standards and tailor it to your needs. For example, the Barr Group Coding Standard which is a C programming standard. It's available as a PDF, but it's also available in a word document that people can, can use and tailor to their own needs. And what I really recommend is that, you know, take that Coding Standard, decide what's applicable to your team and what rules are applicable, add in other rules that you want to introduce. Maybe from the muse recoding standard or the serve that's Computer Emergency Response Team, security--

Andrew:  The serve standard, right?

Dan:  The serve standard which also has valuable rules. There's certainly a large intersection between all of these standards but, you know, take, pick and choose what's applicable, put into the document and use that and start with that. That's a good, good way to go.

Andrew:  Okay. Good. Another question I get is this whole concept of legacy code, you know, I hear this all the time, engineer will come and say, you know, I took our code that exists, that is not subject to a Coding Standard. I ran in through Static Analysis tool and I ended up with hundreds or even thousands of warnings and errors. And it becomes very daunting to them. You know, they ask me. So, so is it important to fix all these errors?  How important is it to fix all these warnings and errors?

Dan:  Yeah. So, there are a few things to say about that. One is as soon as you started making any changes to your code base because of warnings from Static Analysis tool. It's possible that you're going to accidentally break something in the process.

Andrew: That's right. You can create errors by fixing error.

Dan:  You certainly can. And there are well-known cases including introducing some security flaws. I don't have time to go into those right now, but it's absolutely a trap. So, one of the ways you protect against that is by having a good, solid, regression test suite. So, that when you make these changes you can be testing along the way and making sure that you haven't broken something, because that's a reality. But as far as getting back to your question about introducing, you know, tools and coding standards and how do you do that legacy code. What we usually recommend is apply these new things to your new code as you're going along.

Andrew: Right.

Dan:   So, don't try to tackle all the legacy code initially, but as you're introducing new features, adding new modules, apply the coding standard, run static analysis on this which increases the overall quality of your software as you're going.

Andrew:  Sure.

Dan:  And then as you have to go into legacy code to make changes for maintenance, you can consider whether or not you want to introduce the coding standard and legacy code into that or the static analysis tool as well. That's really on a case-by-case basis.  So, that’s probably what I would say.

Andrew: Okay. It's good. No, that makes sense. So, I guess still going back to legacy code because sometimes, you know, engineers will then have to report to their managers and all of that about that. If there are hundreds or thousands of warnings or errors on legacy code and a team does decide they want to go back and update their code, does that mean that it has to take thousands of hours to fix all of this or are there ways to reduce the amount of time it takes to make code compliant when you start off with a legacy code base that may have thousands of errors or warnings.

Dan:  Yeah, I have seen that exact scenario multiple times. In fact, in my consulting and training, I've talked with engineers who said, "Yeah, we brought in this tool, we turned it on, it spat out thousands of errors in our legacy code."

Andrew: And they gave up.

Dan:  They gave up. They said, "Turn it back off and we ran anyway, because they closed the closet door and left the scary stuff in there."

Andrew: Right. Sure.

Dan:   You know, and that absolutely happens. That's a reality. But, but the truth is that oftentimes there are a very small number of things you can do to the code, to legacy code that will greatly reduce the number of errors that come out. In other words, a few root causes, a few small changes to your code can oftentimes drastically reduce those thousands of messages into hundreds or even possibly dozens of messages. It's understanding the source of those issues and understanding how you can make a somewhat tactical change to your code. For example, perhaps a change in a header file can reduce a lot of errors. So, it's really not that overwhelming. And it's oftentimes just being familiar the process and knowing what to do, but it absolutely does not mean hundreds or thousands of hours.

Andrew: Right, so engineers if they see those large numbers of errors and warnings before they just panic, maybe take a little closer look at things, understand things a little better and then you can realize that it doesn't have to take, you know, weeks or months to fix that. Okay.

Dan:  That's right. One other thing I should mention is that most of the static analysis tools that I've used, they triage the errors into different categories. Some are what they call errors which are outright.

Andrew:  Okay.

Dan:  We really have to fix them. Some of them are warnings like you should be aware of this. And some of them are just purely informational. So, by deciding ahead of time when you configure the tool what you care about, what's a greatest concern, and what you want to tackle first, you can also kind of limit the scope of what the tool tells you and tackle the most important problems at first.

Andrew:  Okay. That's great. Thanks, Dan. I appreciate it. I certainly hope that more people start using Coding Standards and Static Analysis will certainly be looking for that in our survey in other activities. Thank you today.

Dan:  You're Welcome.

Watch More Tech Talks