Static Code Analysis Tools?

rewt66 asks: "We are looking for a good static analysis tool for a fairly large (half a million lines) C/C++ project. What tools do you recommend? What do you recommend avoiding? What experience (good or bad) have you had with such tools?"

Re:Ideas

[Anonymous Coward]

1. If you have 500k lines in a single project, consider re-factoring it into separate libraries that you can divide and conquer. Also, if you have 500k lines of code, consider cleaning it up, re-factoring it, etc. Fewer lines of code is more impressive than more.

That's great and all, but some things just take a lot of code. Refactoring into libraries only goes so far, you're still going to have a ton of code, it'll just be split up in libraries. That's useful, and it's good advice, but since the poster didn't ask about it, you could at least give him the benefit of the doubt and assume the project is already organized appropriately. Half a million lines isn't that big, certainly not big enough to automatically assume their codebase is organized badly.

Re:Static analysis tool?

[Fujisawa Sensei]

India

That may be part of the problem. Cheap junior programmers from India doing cut'n paste coding.

Re:Ideas

[j00r0m4nc3r]

There's nothing wrong with having lots of code in a project. A solution with 1000 libraries of 500 lines each is no better. Don't break stuff up just for the sake of not having a lot of code in a project. Break it up and refactor it if it NEEDS it for context/architecture/organization reasons.

Re:Ideas

[Anonymous Brave Guy]

I agree that much code is far longer than it needs to be, but I don't think it's fair to equate this with large projects.

IME, large projects (over a million lines, say) often get that way because they have been built around some sort of framework, and the boilerplate code pushes the line count up. When you get past a certain scale -- more than a handful of developers, or with the team split across multiple geographic locations, that sort of thing -- such frameworks can be very valuable in retaining a sane, structured overall design. Since most of it is typically generated rather than hand-crafted, it doesn't really impact on developer productivity; if anything, it helps it, by maintaining some kind of order in systems that are otherwise too large for any one individual to fully comprehend. (This assumes the framework is well designed and not itself wasteful and overcomplicated, of course.)

On the other hand, it is perfectly possible for a library that should take 1,000 lines in a couple of files to expand to 10,000 lines across five different files. This sort of thing can be a killer, with cluttered interfaces to modules, inefficient algorithms written in verbose style, and so on.

Re:Ideas

[Anonymous Coward]

Who said anything about putting all of the source into one build? The OP said he had 500Ksloc of code that were used to build his project. He never said it was all in one module! It seems to me you (and just about everyone else) have made a ridiculous assumption about his codebase and just run with it.

I've seen projects in the 1.5Msloc range, but they were broken down into 1500+ different modules to make them managable. It was all homegrown because there were no free or commercial alternatives to any of the pieces. But when it came to enforcing code quality measurements and reviews we applied the same standards to all homegrown components. From the program manager's perspective we were applying tools to a "1.4 Msloc project". It doesn't mean we kept all of the source in the same .c file, or even in the same directory, or even controlled by a single Makefile. It is much more likely that the OP is in a similar situation.

I'm curious, do you think the Linux kernel and/or any of the BSDs are badly managed projects just because they have a lot of source? Or do you not consider the Linux kernel a single project even though you can build it with a single "make" command?

As for the codecs, both libflac and libvorbis are in the 40-50Ksloc range, not counting testing code. If I want to write an audio app unencumbered by the GPL I'd need *something* to replace that code. How I organize the build doesn't change the fact that there will be an extra 80-100Ksloc of code that goes into my app that will need to be vetted and maintained. For all practical purposes the code size of the project just went up, even though the modules are separate. In an ideal world those modules could be reused by other projects, but in reality there are many cases where we modularize the code for maintainability but never see any demand for reuse. Crypto and A/V codecs probably end up with high reusability, the software inside an F22 probably does not.

Re:It All Depends on Context

[mwvdlee]

And part == project?

Is is SAP a single project, and are all those individual parts considered projects too? Perhaps a single .DLL is a project internally.

You seem to be missing the point that there is no clear definition or scale for a project, atleast not in the world outside of yours where every single compiled module seems to be a "project".

In real-life, a project may be anything from rebuilding an entire set of applications to fixing a typo in a batch file.