Slashdot Mirror


What is a Good Open Source Code Analysis Tool?

carlmenezes asks: "I volunteer when I can to help a poor educational institution in India with their computing needs. As you can imagine, most computers are from donations and very little money (if any) can be spent on software licensing. Therefore, the installed software is all Open Source and I do all of the software installation by myself. I have already installed Linux on 16 PCs, with Firefox. The default desktop is KDE and the kdeedu package (klettres in particular) has several loyal fans. Incidentally, the kids don't find it hard to use at all and the lack of 3D doesn't bother them in the least :) I would like to ask the community about a good source code analysis tool. I have already installed Source Navigator. Is there any other comparable open source tool?" "The analysis tools would be for those students that show more interest than the others in programming. There is a lot of source code in there for them to look at it if they want to. I'm looking more at C/C++ than anything else. There are some very bright students and I would like them to be able to move beyond ordinary school programming if they feel like it. No, there is no Internet connection. I bring in the software on CDs and install it."

6 of 53 comments (clear)

  1. Use Java instead by nganju · · Score: 4, Informative

    There are two very good open source IDEs for Java, NetBeans and Eclipse (I personally prefer Eclipse).

    If you're teaching beginners how to program, Java is simpler anyway. You don't have to understand memory allocation and pointers because it's all taken care of for you. Also you can write non-object-oriented programs to start with by making all functions static.

    This way you can start with very simple programs and work your way up to introducing more advanced concepts, like object-oriented, or memory allocation etc.

    If you insist on learning with C/C++, I would lobby with the executives at a company like Borland. They usually have the power to throw a few copies your way, as long as they're convinced that it is a philanthropic effort (it makes them look good).

    --
    There are 2 kinds of people in this world. Those that can keep their train of thought,
  2. Cscope, Lint by n1ywb · · Score: 5, Informative
    From the Cscope web site:
    Cscope is a developer's tool for browsing source code. It has an impeccable Unix pedigree, having been originally developed at Bell Labs back in the days of the PDP-11. Cscope was part of the official AT&T Unix distribution for many years, and has been used to manage projects involving 20 million lines of code!

    In April, 2000, thanks to the Santa Cruz Operation, Inc. (SCO) (since merged with Caldera), the code for Cscope was open sourced under the BSD license.

    • Allows searching code for:
    • all references to a symbol
    • global definitions
    • functions called by a function
    • functions calling a function
    • text string
    • regular expression pattern
    • a file
    • files including a file
    Curses based (text screen) An information database is generated for faster searches and later reference The fuzzy parser supports C, but is flexible enough to be useful for C++ and Java, and for use as a generalized 'grep database' (use it to browse large text documents!) Has a command line mode for inclusion in scripts or as a backend to a GUI/frontend Runs on all flavors of Unix, plus most monopoly-controlled operating systems.

    From the Split (a modern version of Lint) web site:

    Splint[1] is a tool for statically checking C programs for security vulnerabilities and programming mistakes. Splint does many of the traditional lint checks including unused declarations, type inconsistencies, use before definition, unreachable code, ignored return values, execution paths with no return, likely infinite loops, and fall through cases. More powerful checks are made possible by additional information given in source code annotations. Annotations are stylized comments that document assumptions about functions, variables, parameters and types. In addition to the checks specifically enabled by annotations, many of the traditional lint checks are improved by exploiting this additional information.

    As more effort is put into annotating programs, better checking results. A representational effort-benefit curve for using Splint is shown in Figure 1. Splint is designed to be flexible and allow programmers to select appropriate points on the effort-benefit curve for particular projects. As different checks are turned on and more information is given in code annotations the number of bugs that can be detected increases dramatically.

    Problems detected by Splint include:

    • Dereferencing a possibly null pointer (Section 2);
    • Using possibly undefined storage or returning storage that is not properly defined (Section 3);
    • Type mismatches, with greater precision and flexibility than provided by C compilers (Section 4.1-4.2);
    • Violations of information hiding (Section 4.3);
    • Memory management errors including uses of dangling references and memory leaks (Section 5);
    • Dangerous aliasing (Section 6);
    • Modifications and global variable uses that are inconsistent with specified interfaces (Section 7);
    • Problematic control flow such as likely infinite loops (Section 8.3.1), fall through cases or incomplete switches (Section 8.3.2), and suspicious statements (Section 8.4);
    • Buffer overflow vulnerabilities (Section 9);
    • Dangerous macro implementations or invocations (Section 11); and
    • Violations of customized naming conventions. (Section 12).
    --
    -73, de n1ywb
    www.n1ywb.com
  3. The best tool is the human body by JPyObjC+Dude · · Score: 4, Insightful

    Just do the following:

    1) Learn how to program.
    -- nuf said.
    2) Write clean code
    -- Proper indenting **
    -- sufficient commenting
    3) Less code is more
    -- More lines is more intimidating that less
    -- However, there is a limits (ie Perl)
    -- More you can fit on one screen the easier to debug
    4) Be a structured programmer
    -- It should not matter what language you are programming in. The structures should always be the same.
    5) Learn and use language level error handling
    -- This will enable you to fully understand how to debug your code
    -- Stack traces are a must for any procedural or OO code
    6) Make your programs chatty
    -- Log files are good but make sure there is a way to easily turn off logging features so that you can speed up programs when you are happy.
    7) Learn how to tail log files
    -- tail is available on every operating system
    --- GNUUtils for win32
    --- *nix (Linux, Unix, OSX ...)
    8) Write blind code as much as possible
    -- IDE's are very powerful but I always write all my code in a text editor totally blind (no compilation, syntax validation...)
    -- If you become dependant on the system to tell you what is wrong, you will not learn to SEE the problem.
    --- Often times, when I get an error and I know I just changed a piece of code I will not even read the error. I'll just look at the line of code that I changed and visually look for the error. If you don't learn how to do this, then programming probably is not for you.
    9) Got errors, don't worry
    -- All coders get errors.
    -- Only a few times I have written dozens of lines of blind code and not gotten at least one error. I was amazed when I did.
    -- Don't get stressed out. Just be pragmatic and move being objective with the error.

    That's probably a good start.

    Personally I would not trust programs in telling me where coding problems are anyhow. I find it akin to using anti-spyware programs on a win32 box where it would be easier to just not use IE and be more concious of the operating system we use. The latter takes a little more understanding but in the end all will be better :]

    JsD
    (Java+Python+ObjC-on-BSD-with-firefox==happ iness:)

    1. Re:The best tool is the human body by angel'o'sphere · · Score: 4, Insightful


      8) Write blind code as much as possible
      -- IDE's are very powerful but I always write all my code in a text editor totally blind (no compilation, syntax validation...)
      -- If you become dependant on the system to tell you what is wrong, you will not learn to SEE the problem.
      --- Often times, when I get an error and I know I just changed a piece of code I will not even read the error. I'll just look at

      Thats probably a good way for learning programming (I learned like that, because today tools where magic at my time), but I doubt its a good way to work.
      With a good IDE you are ten times faster than with notepad like simple editors. Even VI or VIM with a good ctags/jtags support and codecompletition is already nice.

      For C++/Java etc. use Eclipse.
      For Java use Eclipse/IDEA IntelliJ or CodeGuide (in reverse order).

      Probably you should determine the language you want to teach first. If you use Python, you should look for a decent Python IDE.

      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  4. valgrind by yamla · · Score: 4, Informative

    valgrind and associated add-ons, are absolutely amazing and quite useful for C and C++ programming.

    Nobody should be caught dead writing C++ programming without at least knowing about Boost's libraries. Not really analysis tools but useful nevertheless.

    --

    Oceania has always been at war with Eastasia.
  5. linux cross reference by StyXman · · Score: 4, Informative

    lxr (http://lxr.linux.no/) was dveloped with the kernel in mind, but now it works with any C, C++, python, perl and other laguajes (those supported by exuberant-ctags). I used it in several projects and, in conjunction with tabbed browsing, I think it's all I need. Dependencies are: mysql, perl, apache, exuberant-ctags.