Sunday, August 22, 2004

Answers for Amit.

There can only be two aspects when one "masks" some rules.
1) You are intentionally keeping known bugs in the system (both in cases when you know that you don't stand to gain from the fixes and when you want to push stuff under the carpet :) )
2) The tool you are using gives a large number of false positives and hence you end up masking the rule.

The second one is a problem that good tools have/will solved and the first depends on your judgement and integrity :)

Anyways consider that you have a certain constraints in the system where-in some valid code forms a of a pattern that is considered as a bad practice (also called an anti-pattern) under the programming framework (e.g. J2EE, J2SE etc). Such bad practices need not be given as input by the programmer. All such rules can be pre shipped by the tool vendor and maybe extended (if needed) by one of the project members and reused by all.

2 comments:

Harshal said...

Hmmm ... seems to me like you are doing lots of thinking about static analysis tools. AFAIK, Rational doesn't have anything that comes close to what people like Coverty are doing. If I connect the dots a little bit ... can I speculate that that hole in their suite of tools will soon be filled ? :)

You mentioned coverty. There are lots of others in the fray. I hear that smatch is an open source thingy based on similar ideas. I hear it works off gcc's intermediate parse tree. You might also want to check out sparse. It is designed for the kernel, so I imagine it will be too specific for whatever your purpose is. And it relies on code annotation to be really effective, so thats a pain. But anything that Linus designed and wrote himself is worth checking out anyway :)

I remeber hearing somewhere that Microsoft has very good tools that they use internally for some of this stuff. But so far they have hesitated to release them as part of VS for business-driven reasons. They do have FxCop for .Net apps. Checking that out has been on my list of things to do for a while. Dunno exactly how far it goes and how good it is.

Anyway, the major problem with static analyis tools so far has been that they have to duplicate too much of what the compiler already does. They need to "understand" the code at the same level as the compiler does basically. gcc has historically been fanatical about saying that their internal intermediate representations were all private and they didn't make it easy to use them at all. The good thing is that with the advent of VM's (and in particular .Net with a really strong set of API's that talk to CLR IL) this problem is kinda going away. IL is probably the right layer to do these kinds of things anyway. Looks like the gunky and ugly site of builing static analysis tools will go away. Letting people focus on the interesting and important bits of the problem ... and that can only be good.

Anonymous said...

Neeraj, I know that by masking rules you are raising doubts about integrity of the developer, but here is the real catch 22 situation: If you honestly follow all rules of a static code analyzer being run on a code which had a hap hazard software design (which is quite normal) then you may end up redesigning the system or introduce more regression bugs. And if you dont you are shoving bugs under the carpet..So which one do you choose?
This regression thing is a very common phenomenon when u run PC Lint, especially when original developers are not available and a rookie does the job. System re-design is something which costs a lot...so both are generally ruled out by customers...Also these tools replicate lot of work that a compiler can also do, so why not add some more rules during compilation itself and save time and money in runing and buying static analysis tools? The money thus saved can be well spent in buying some more licenses for tools like rational rose, which will atleast enforce robust s/w design itself :-) If I were a manager for a new development project I would buy better s/w design tools than waste money buying static code analyzers. And for projects where source code already exists, I would live with bugs and fix the important ones rather than re-designing or introducing regression bugs in the system, which is what clients usually ask for....