In my previous post, It’s time to create a custom checker…, we looked at the considerations involved in deciding which checker to create–AST or path?

In this post, we’re going to use a custom checker to enforce an internal coding standard that extends the default set of checkers in our source code analysis tool.

To do this, I’ve called upon Steve Howard, our head of Partner Support in Europe, to get us started with an AST checker to accomplish our goal.

Steve has coached many customers through the checker creation process. In his experience, the appeal of custom checkers lies in their ability to enforce naming conventions and code constructions across organizations.

The standard we want to enforce is the use of a compound statement block rather than single statements as the body of a for loop. An AST checker is the way to go because detection depends solely on the syntax of the code itself and not runtime behavior.

See the example below:

To flag this violation, we need to instruct the checker to find all instances of for loop nodes that contain a Statement node as an immediate descendant.

A tool that shows you a visual representation of the AST for the test case is quite helpful in the checker creation process. Here at Klocwork, we use Checker Studio to:

• browse the AST structure of test cases,
• identify nodes of interest, and
• test XPath-like expressions that identify node types, qualifiers, conditions and variables to traverse the AST and flag the defect.

Note: If we wanted to enforce the compound statement rule in all loops, then we’d need to have one pattern (created using the XPath-like expression) for each possible kind, such as while loops and do while loops.

Armed with the test case, Checker Studio, and a syntax guide, Steve identified the following expression that flags the infraction:

// ForStmt [not (Stmt::CompoundStmt)]

Here’s how the test case and expression appear in Checker Studio:

Golden rules

Based on his experience, Steve has a number of golden rules that get you from idea to defect detection faster:

• Start simple: Use a simple test case that contains the defect you want to detect and work with one simple pattern at a time. Add more complexity as you go along
• Start rough and refine later: Don’t worry about false positives at first. In some cases it may even be easier to search for  instances that are OK and then negate the rule at the end
• Divide and conquer: With a more complex checker, work separately on each aspect of the defect you want to detect and then bring it all together at the end for testing in Checker Studio
• Watch your levels: Make the highlighting as relevant as possible for the issue you’re trying to find. For example, “// ClassType [MemberDecls[*]::MemberDecl]” will highlight classes that match, whereas “// ClassType/MemberDecls[*]::MemberDecl”  will highlight class members that match. The rule is the same, but the focus is different
• Weed out false negatives: Add negative examples (good code) to check for false negatives

For more information about our custom AST checkers, watch our Checker Studio video.

You’ve been using source code analysis on your integration build or your desktop, or (ideally) both. And then there’s “a situation”.

The situation

Either you:

• Noticed a false negative you want detected, or
• Need a way to enforce a corporate coding standard, such as the requirement for the use of  a compound statement block rather than single statements as the body of a loop.

Now what?

Time to create a custom checker, that’s what. But what kind of checker?

Source code analysis involves two families of checkers, those that involve:

• Abstract Syntax Tree (AST) validation, and
• Code path analysis.

An AST provides a tree-based structural representation of the source code. An AST checker allows you to pinpoint problematic syntax using XPath or XPath-derived grammar to define the problem you’re looking for. AST checkers (our version is called Klockwork AST checkers, or KAST for short) don’t require program execution to run; they detect defects right away on source code.

Code path analysis, on the other hand, targets defects related to value tracking at program execution time. Instead of style violations, you’d use a path checker to answer questions such as:

• Is this newly-created object released before all aliases to it are removed from scope?
• Is this data object ever range-checked before being passed to an OS function?
• Is this string checked for special characters before being submitted as an SQL query?

To create a path checker, you don’t need to know how data is tracked by the checker. What you do need to know are the function types and values you want to track for the analysis starting point and the analysis end point where the defect (or event) is recognized and reported.

Which checker when?

Create an AST checker when the problem you want to detect:

• is a local defect
• does not involve program execution
• has to do with the way the program was written
• does not involve tracking a value
• does not involve a path

Create a path checker when the problem you want to detect:

• involves tracking a value
• has a starting point (where the analysis starts) and end point (where the defect is detected)
• involves program execution

Stay tuned for the next post in this series on best practices for AST checker creation.

For more information, see Writing custom checkers with Klocwork Extensibility or check out our member discussions in the C/C++ custom checkers forum.

–With files from CTO Gwyn Fisher

Klocwork Developer Network presents Klocwork University, which consolidates all our online learning resources onto a single page.

Klocwork University is your one stop for self-paced online learning and how-tos about:

• Setting up and using our static analysis tools on your desktop or integration build
• The latest trends in software security
• Agile coding practices and how they intersect with static analysis
• Klocwork product overviews

At Klocwork University you’ll see helpful descriptions of:

• In-house and partner-generated e-learning courses
• Video how-tos
• Webinars

After you browse our offerings on the Klocwork University page, click your selection and access your resource. If you’re not already logged in to the Klocwork Developer Network, you’ll be prompted to log in or register to use these free resources.

This change pulls the course content descriptions from behind the login wall to provide a searchable list for members and non-members alike.

At Klocwork University, you get the information up front and you can schedule your pub breaks when and where you want. Join today. There’s no free beer though.

Michail the friendly, programming vampire.

Instead of fomenting dissent (that barely exists) in a brazen attempt to boost readership, I’m changing tactics to look at ways in which testing and development are complementary, beyond their common goal of releasing quality software products.

What can I say? After my previous post, How developers drive testers nuts–let’s count the ways, I’m clearly getting less edgy.

I approached our newest addition to the Klocwork development team, Michail Greshishchev. While he’s a new full-timer, Greshishchev is not a new face around here.

The recent Carleton University engineering graduate did two co-op terms here–one in professional services and the other in testing.

So I asked Greshishchev how his stint in testing affected his development. Here’s exactly what he said:

1. Writing short, efficient unit tests comes naturally after dealing with mammoth testing frameworks. Most of the code I write are tests – the techniques and skills I’ve learned in testing are fully applicable to development.
2. Developers have no idea how to execute a test in our automated test system (I don’t blame them–the test machine is a large, well-oiled beast distributed over dozens of operating environments). Having the knowledge to run test team tests on developer builds means I don’t need to wait for nightly build test results to address issues. More importantly, I can add my own tests to the test team’s automated test system.
3. It’s common for a developer to request more information about a tester’s problem report. My experience with the test team allows me to access the information on test machines myself, saving time for everyone.
4. The test report pages actually make sense. This allows me to investigate test failures in the nightly build before a tester comes to my desk to tell me I broke something.

His experience as part of the test team has been win-win for him and his colleagues. Testing and development sound like allies, don’t they? Well, as much as werewolves and vampires can be allies, I suppose. And he was such a nice guy too, but the change is upon him.

Crying into your wadded Kleenex about how your vulnerabilities were exploited may make for compelling TV, but when it comes to software security, they’ll cost you a lot more than your personal dignity. Or maybe they’ll cost you millions of dollars in lost business and your personal dignity.

Why not toughen up your code by implementing software security best practices that prevent or mitigate the risks?

That’s why you should head on over to the Klocwork Developer Network and check out the free eLearning courses provided by Security Innovation, an industry leader in software security and cryptography. To view learning resources, just log in or register.

Here’s a brief description of each course:

• OWASP Top 10 – Threats and Mitigations

Learn strategies and best practices for understanding, identifying and mitigating the risk of vulnerabilities and attacks within the OWASP Top 10.

• Intro to the Microsoft Security Development Lifecycle (SDL)

The Security Development Lifecycle (SDL), a key security engineering process that was spawned from Microsoft’s Trustworthy Computing Initiative. Learn the necessary steps to meet SDL requirements, and identify the appropriate tools required by the SDL.

• Intro to XSS – Asp.Net examples

Learn to understand the mechanisms behind cross-site scripting vulnerabilities, describe cross-site scripting vulnerabilities and their consequences, and apply secure coding best practices to prevent cross-site scripting vulnerabilities.

• Intro to XSS – Java

Learn to understand the mechanisms behind cross-site scripting vulnerabilities, describe cross-site scripting vulnerabilities and their consequences, and apply secure coding best practices to prevent cross-site scripting vulnerabilities.

Have fun, code safely and put that Kleenex away (unless it’s allergy season).

The two sides of testing team lead Jonathan Patchell.

At daily standup meetings, they eye each other from opposite sides of the room. Sitting on the same side of the cubicle wall is unthinkable.

They’re united only by their desire to produce quality software products and their appreciation for coffee and energy drinks. What’s good to one side can be anathema to the other when it comes to code.

I’m talking, of course, about testing and development teams. In the interests of generating more comments improving dialogue between two very important functions in a software organization, our marketing director asked me to interview our testing team lead, Jonathan Patchell, about the ways in which developers drive his team nuts.

Patchell, a computer systems engineer, has been with Klocwork for five years and a team lead for two. He struck a fairly conciliatory tone for this interview, which sorta ruins the adversarial approach, but don’t let his diplomacy fool you. I’ve seen him suffering as the release date approaches and his demeanour changes completely.

Here are Patchell’s top dev peeves:

What comes first—the process or the tool?

Yes.

Any tool worth its salt should integrate into existing processes and tools.

What’s interesting and informative is seeing the similarities and differences in how the same tool is applied in different organizations, across continents and oceans.

The emphasis on quality unites everyone, but the level to which agile is adopted is what makes static analysis markets different.

No one knows this more than Mark Grice, Klocwork Director and Manager of the International Reseller/Partner Network, and Steve Howard, head of Partner Support in Europe.

Trying to talk to these guys at the same time is a challenge. Mark’s work takes him all over Asia, but I managed to pinpoint him in Japan; Steve spends most of his time traveling across Europe, but was at his home base in England—for a time, anyway.

Same difference

The European and Asian markets are all singing from the same song book when it comes to coding standards.

“MISRA is very appealing here in Europe, particularly on the developer desktop,” Steve says.

“There’s a strong focus on quality here,” Mark says about his Asian market. While MISRA is “somewhat appealing,” Mark says he gets asked about Embedded System development exemplar Reference Series (ESxR) quite a lot. It’s a coding standard similar to MISRA in that it’s aimed at embedded system development, but its adoption is more Japan-centric. For more information, see ESxR at Information-technology Promotion Agency, Japan (IPA).

Steve explains  that the ability to extend checkers to suit the needs of specific organizations is of keen interest to customers in his bailiwick.
“Sometimes organizations want to enforce their own naming conventions or code constructions, and the extensibility tools provide a very quick and effective way to accomplish that,” he says.

Difference

The developer desktop illustrates the great agile divide.

“I’d say Europe is a little bit behind North America in its adoption of agile, but there’s still the same requirement for developer productivity and speed,” Steve says.

For that reason, he sees more opportunity to penetrate the European market with a static code analysis tool for the developer desktop. The growing interest in agile in Europe gives him an increasingly receptive audience.

Japan is a bit different on this score from the rest of Asia.

Quality is seen as the purview of testing teams, and not development. That means that there’s a huge focus on quality at the end of the development life cycle, rather than the beginning, Mark explains.

Desktop source code analysis tools are a harder sell in Japan, but that may change as agile processes trickle in.

And there you have it, a quick peek at a couple of our markets.

Do internationalization and localization take the fun and flexibility out of documentation?

And here’s the answer: You betcha, sister!

At the risk of starting a brawl in the documentation department, I’m going to respond  to my manager’s post about our new policy to facilitate the translation of our wiki . It’s a policy I refer to unaffectionately as the Stamp-Out-Fun-and-Flexibility policy.

And yeah, I know that internationalization and localization are important to humanity and, um, sales. It’s just that making things more translatable makes documentation less agile and less fun.

1.    Wikis are agile until you’re not allowed to edit them

The great thing about our wiki is that we can update it during development and post release. Customers don’t need to wait until a new version is published. It’s always current.

The policy sucks because: We’ll have to have a “freeze-by” date to get material out of translators. Changing the docs will lead to higher translation costs. So that run-on sentence and that wrong instruction will go unfixed until the next round. The PR fix that has user impacts will go undocumented until the next release.

2.    So long community

All along, we’ve encouraged customers, partners and internal teams to edit our documentation.

The policy sucks because: Now, we’re going to have to say, “No editing. Yeah, yeah, I know we said to go ahead and edit, but really what we meant was don’t edit.” Our “yes, go ahead and edit” was mistranslated.

3.    Google loves fresh meat.

For SEO, churn is great. Search engines love to have fresh material to crawl all over.

The policy sucks because: Less content churn is bad for findability.

4.    A fun, engaging tone makes documentation more readable.

A light tone, particularly in error messages, can defuse frustration.

The policy sucks because: Our writing will have to go back to being dry, dry, dry. No more “Why you’re here”.

What are the predictions on the outcome of this fight? Well, I lift weights occasionally, but Helen fights dirty. It’s anyone’s guess, but I think I’m going to lose this one. That’s okay. I’m used to it.

Klocwork developer Russ Sherk sporting his mo'stache. It's hair today, gone tomorrow.

Time’s a precious resource, so the saying goes. Don’t waste it. That’s particularly true for developers, who live in the critical path lane.

And if there’s someone who knows a lot about time management, it’s Russ Sherk, an intermediate developer here at Klocwork, and the father of three young ‘uns. Russ works on our Klocwork Review and Klocwork Inspect products and handles licensing.

For Russ, these are lessons learned over his six-year tenure at Klocwork.

“These are things you need to think about or you won’t progress as a developer,” he says.

Here’s what to do if you want to waste time:

1. Code without a plan

It’s easy to get carried away with ideas about cool features, Russ says. This is how you burn through the days–by doing a lot of things that don’t need to be done.

The fix: Classic agile philosophy. “You have a story. Then break it up into a list of features that must be done. You take those features and you break them down into tasks taking less than a day, Russ explains. A task taking two to four hours is optimal. The team here uses XPlanner for project/story/task management. You can always augment with pieces of paper.”

2. Switch tasks constantly

Mental switching eats up a lot of time because you need to evaluate where you were before you switched gears, and then go through it again when you switch back.

The fix: Get to a completion point before switching (if you can).

3. Take the idealistic approach to bad or “delicate” code

Inheriting problem code makes debugging and feature work more difficult and error prone, Russ says.

“It’s tempting to want to fix it all–but that will always set you back.”

The fix: Fix what you touch to the best of your ability. Schedule larger-scale refactoring and reorganization work separately.

4. Build infrequently

This strategy goes beyond the individual developer.  There was a time here when there were only weekly builds (Egad! Say it ain’t so!). Even 15 minutes per build slows you down, Russ says. The push by development managers for frequent builds has paid dividends.

“Now, I can go through a build process in 2-4 minutes,” Russ says. That translates into 10 to 15 builds a day.

The fix: Frequent build cycles allow you to make your changes, verify them, and handle bugs quickly.

5. Optimize early and over-engineer

This is the dark side of planning. Over-planning and perfectionism can be paralyzing.

The better approach is to keep it simple, he says.

The fix: Plan the bare minimum to get your feature working. After the feature is in place, it’s time to optimize and refactor.

And there you have it. Surprisingly, World of Warcraft didn’t even make the list.

Want to get rolling with a Source Code Analysis (SCA) tool as efficiently as possible?

“Do what the smart companies do,” says Mark Grice, a Klocwork Director and Manager of the International Reseller/Partner Network.

In our last discussion, Grice outlined three best practices for SCA tools selection: involve your developers, limit your selection to market-leading tools, and identify a deadline.

According to Grice, smart companies take those best practices and:

“After the six-month period,” says Grice, “a company will widen its deployment circle and get more licenses.”

On the other hand, Grice says it’s also possible that the company will decide to try another tool from their panel of tools. They won’t need to re-evaluate because they’ve got a short list to pull from.

“They don’t lose, whichever way it goes,” he says. “During that six-month period, they got value from that tool by applying it to their codebase, learning about SCA and cleaning up their code.”