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

As a pretty avid Apple user (2 iPhones, 1 iPad2, iMac, iPod Touch, MacBook Pro, etc.), and the fact that I work in the business of software quality and security, I must admit that this article caught my attention. The article outlines how a well-known security researcher, who focuses on Apple, has found a software flaw in the iPhone and iPad, which could allow hackers to build malicious apps.What makes this even more scary is that the Apple Store may not catch these malicious apps.

To add another twist to this story, the researcher in question has been ejected from participating in Apple’s developer programs. Read about that here.

Are we now getting to the point where hackers are going to start trying more aggressively to exploit Apple products? In a survey done in 2010, over 50% of respondents thought Windows was either “very” or “extremely” vulnerable compared to only 20% for Apple. I wonder if that has changed? More importantly, do I need to start worrying about my daughter downloading the Archie comic app from the App Store?

The question of “what’s the right iteration length” may not be as interesting as any of the questions found here (gum really doesn’t stay in you for 7 years. Who knew?), but it is a common question from organizations moving to agile development. You can certainly get a lot of different opinions on this from a Google search, but since you’re reading this now, I’ll give you mine, based on personal experience.

A number of years ago, one of the projects I was PM on decided to try out Scrum. I had attended some Product Owner training, and our soon-to-be Scrum Master had been on some training as well, but we were very green and decided to approach things with a “let’s see what works best for us” mentality. At the time, we thought the best way for us to get immersed and efficient with Scrum was lots of repetitions. We went with 1-week iterations, thinking that by having a rapid and regular cycle of sprint planning meetings, demo meetings, retrospective meetings, etc. we would learn more quickly the “proper” way of doing development with Scrum.

We certainly did learn a lot during our first 3 or 4 sprints, mainly that having this regular weekly cycle of meetings was just too much overhead, and the actual amount of value produced at the end of each sprint was too little. Next on our list, the 2-week sprint.

The 2-week sprints worked great for us, and we saw the differences from the 1-week sprints almost immediately. We were producing what we thought was a good amount of value from each sprint, but with a better and more balanced level of overhead. We hit our groove and established a good cadence with these 2-week sprints, and from the looks of the burn-down chart, we were becoming a more efficient team with every sprint.

The team definitely was cruising and enjoying the pace, but the holiday season snuck up on us and we thought that it might make sense to make some adjustments to deal with the vacation time various team members would be taking.

After collecting everyone’s vacation schedule, we were able to determine a start and finish date for our “holiday sprint” that would essentially start when everyone was still in the office, and finish when everyone returned from their vacation. Call it either luck or good management, but we had planned a 4-week sprint. I won’t go through all the gory details, but let’s just say that upon reflection, the 4-week iteration just felt wrong.

The initial planning session felt harder to estimate the amount of work we could do. The cadence we developed didn’t show itself, and it really felt like we never gained any momentum during the 4 weeks. Now I’m sure that the whole holiday season thing played a role in this, but it was our least effective iteration ever, and by a lot. We never tried the 4-week iteration again.

The bottom line is that all teams are different and need to go with the iteration length that feels right for them. For us, the 2-week one was best.

For the record, I have always wondered if the 7-year rule for chewing gum was true. Glad to hear it isn’t.