Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Is there a fundamental difference between these tools? After all, klocwork is relatively expensive and the other ones are free? Both do static code analysis after some rules.
Are there differences in the quality of rules? Does it only depend on the rules? What is your experience?
You get what you pay for, both in the depth of the checkers, and in defect tracking and false-positive suppression. cppcheck and the Clang static analyzer are worth running, and find a reasonable number of shallow but serious bugs, even in a good codebase. (We run the Clang analyzer first, with the settings file turned to the max with help from https://github.com/jonreid/XcodeWarnings. cppcheck occasionally finds some bugs missed by it, but similar in character.)
Klocwork, and its rival Coverity, both find much deeper bugs in C/C++, sometimes breathtaking in their depth of analysis. Coverity, though, has been taken over, and made little progress in its C/C++ checkers in the last decade; but they are still worth running. (Their JVM checkers are not.) I haven’t used Klocwork recently, but they also are no longer independent. (See my Dr Dobbs article for more detail, http://www.drdobbs.com/testing/deploying-static-analysis/240003801)
(pablo285, both Klocwork and Coverity have well-documented APIs to let you write your own checkers.)
LLVM has a tool for static analysis called Clang static analyzer.
Clang static analyzer and cppcheck are open-source (allowing you to write your own checks/modify existing ones) vs klockwork being proprietary (has an API to write your own checks).
As for the quality of the checks - you'll have to try for yourself, I'm trying to base this answer on facts, not opinions. Nothing prevents you from using more than one static analysis tool though.
Clang-tidy is a little different, it calls itself a "linter" tool and while it can be used for static analysis it also provides automated fixes for some of the defects it can find. Internally clang-tidy uses an abstract syntax tree to represent your code. In order to build this AST the code has to be compile-able by clang which can be a (possibly major) drawback in some codebases.
For list of clang-tidy checks that provide automated fixes see this answer.
I believe clang-tidy or cppcheck engine does line by line analysis. Klocwork engine in other hand, does inter procedural analysis. Klocwork can detect file dependent issues as well what most of other tool cant detect. Klocwork is very powerful in finding critical detects like memory leaks, Buffer Overflow, NULL exceptions, Dead Lock, concurrency issues, etc..,
we have evaluated multiple Static code analysers and ended with Klocwork.
I will tell you why we have chosen Klocwork than any other SCA tools,
Number of Checkers to detect possible vulnerabilities. Klocwork has
more than 1000+ checkers to detect coding defects/issues.
Klocwork can work at developer desktop. So it makes the code bug
free at the time of development. (It has post check-in capability as
well)
klocwork has direct plugin available for Visual Studio, Eclipse,
Intellij IDEA, Wind River, CCS and Eclipse based IDEs. Klocwork has
its own IDE as well. (If you are using any other IDEs than what
Klocwork plugin supports, you can use Klocwork IDE. Klocwork IDE can
work with any Editor or IDE you have)
Klocwork supports checking almost all industry standards like Misra,
Autosar, CERT, CWE, DISA-STIG, OWASP, etc..,
You can write your own checkers in Klocwork to maintain/check your
internal coding guidelines.
Effectiveness in finding the Vulnerabilities issues .
Reporting and Metrics (100+ reporting formats and 400+ metrics)
Filtering the issues – remove 3rd party code in report, create
module report, team report, etc..,
Fast – Though they create AST based on your native build settings
still Klocwork engine is fast and effective.
Automation – Automation – Automation. Klocwork build can be
automated as it has rich command line tools. Plus, Klocwork has
direct plugin available for Jenkins and Teamcity.
Simple Deployment – Client server architecture
Documentation – Documentation and Demo videos of Klocwork is
available online (Open). You just open google and say, “Klocwork C
and C++ checker list” you will get the list of Klocwork checkers
with proper explanation.
Support – Klocwork support team is very user friendly.
Licensing – Simple licensing. No hidden charges.
I would say, take up a free evaluation of Klocwork and test it on your project. I am sure you will love it.
yes, there is a fundamental difference between the clang-tidy or cppcheck compare to klocwork.
Klocwork wrapper will watch your build and creates build specification file based on your compiler name build settings including customized system calls. using this build spec file Klocwork does interprocedural analysis and creates abstract syntax three in back end. then it will try to cover 100% code and 100% path. So Klocwork analysis will be more accurate and it can detect the real defects in the code.
Klocwork can detect data flow issues as well.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I know a bit of C++ and C and the project I am working with now is a whole lot of MFC programming. Can someone experienced tell me the prerequisites for learning MFC.
Also, What the are best sources to learn from ?
Any particular book or video series?
I know the question is too general but answers might help me(or anyone else who is digging into MFC) a lot
Thanks!
+1 Good question!
tl;dr: Learn Win32 - in that order.
By far the most important prerequisite to MFC is a solid understanding of the Windows API (also sometimes referred to as the Win32 API). You will also need to be familiar with a few key concepts of C++ and get intimate with the tools. My proposed list of prerequisites would be:
Get a solid background in Windows API development.
Familiarize yourself with relevant concepts of C++.
Learn the tools.
The following is a rundown of these steps, with links to additional information.
1. Windows API:
The Windows API exposes all services through a C interface. As a consequence resource management is often tedious boiler plate code. And visible in source code (sometimes an incredible bonus when reading code). MFC is - to a large extent - an automated resource management wrapper (and utility library) around the Windows API, hiding most of the resource management and type conversions. To be fluent in MFC you have to understand what it hides.
To get started with the Windows API and all you need is a quick rundown of the major components I would recommend theForger's Win32 API Tutorial (by forgey of #winprog fame). It covers Message Handling, Windowing, Controls, and the GDI, and builds a solid foundation. If you feel like investing (well spent) time into exploring the Windows API in more detail, the best resource to date is probably still Charles Petzold's Programming Windows (not the be confused with the managed Petzold). The MSDN is also a good resource to get both an overview as well as detailed documentation for specific areas like:
Message Handling
Windowing
User Interaction
Windows Controls
2. Key C++ concepts:
MFC is implemented in terms of C++. While it predates the official C++ standard you won't find too much funky business in there. Very little template code and certainly none of the new-fangled C++11 features. Intimacy with basic C++ concepts will get you a long way.
As mentioned previously, MFC is to a large extent a resource management wrapper around Windows API. Often there is a direct mapping between Windows API resources and MFC objects (like HWND : CWnd, or HDC : CDC). If you understand constructors, destructors and object lifetime you're pretty much all set in that department.
When using MFC's template-based containers (like CMap) you will be exposed to templates, naturally. Nothing too involved there, just very basic type parameterization to reuse the container code and enable type-safe element access. An introduction to MFC containers can be found here: Collections.
Exceptions are used rarely in MFC, mostly when accessing files or when serializing data. You should still know how to write exception safe code; you will see exceptions in non-trivial applications. An overview can be found at Exception Handling in MFC.
One area which is not really part of C++ but used extensively throughout the MFC is the preprocessor. Regardless of how trivial your MFC application is, there will be macros. You have to have a very good understanding of both the preprocessor syntax as well as how the preprocessor operates.
3. Tools:
While it is possible to write MFC applications with Notepad alone it is certainly not very efficient to do so. A plain text editor might be a good idea for learning the platform, but when it comes time to meet milestones and deadlines you certainly will want to use a powerful IDE.
MFC pretty much implies the use of Visual Studio and I will assume that's what you're using. If you are using VS6 or VS2010 (or later) you will have access to the MFC Class Wizard. This is a tool you will be using frequently. To safely operate it you must get familiar with the code it generates for you. Play around with it, inspect the generated code, and try to build a mental model of it. If it doesn't make sense yet you should return later.
The MFC class wizard will almost certainly generate preprocessor code. It hides a tremendous amount of complexity which you need to understand to use safely. Use the IDE to navigate through the preprocessor macros, try to expand them in your mind, and see if you understand the resulting code. If you are having difficulty unmangling the macro invocations have the compiler output the preprocessed code for you using the /P (Preprocess to a File) compiler option.
Occasionally you have to look or debug into the MFC source code. To make the source code available to source browsing and the debugger you have to set up the VC++ Directories to include the following (if not already present):
$(VCInstallDir)atlmfc\src\mfc
$(VCInstallDir)atlmfc\src\mfcm
$(VCInstallDir)atlmfc\src\atl
Depending on the IDE this is either done through Tools -> Options: Projects and Solutions -> VC++ Directories or the property sheet of your project settings.
Finding help: While the MSDN is the best resource for documentation, the MFC section feels like it is in maintenance mode and doesn't get as much attention as the Windows API documentation. If you find the MFC documentation lacking look up the respective Windows API documentation instead, for example CWnd::OnNcDestroy vs. WM_NCDESTROY. The latter contains valuable information on the order in which windows receive this message.
Learning MFC
A comprehensive resource for learning MFC is Jeff Prosise' Programming Windows with MFC. While it is dated (released in 1999) the concepts are still valid today. It provides an overview of the concepts of MFC and goes deep into the implementation details. If you find yourself struggling with the generated (preprocessor) code this book is for you.
As a valuable online resource the MSDN offers information on just about any aspect of MFC development. The major concepts include:
Message Handling and Mapping
User Interface Elements
Windows
Dialog Boxes
Serialization in MFC
A full list can be found at Concepts.
The most important prerequisite for learning MFC is C++, followed by unterstanding how Windows works.
My favorite MFC book is Inside Visual C++ by David Kruglinski, who died too early. His last edition covers MFC with Visual Studio 6, but the concepts and most of the content are still valid.
To see how Windows works, the "Petzold" is the book. (Windows Programming by Charles Petzold).
Right now we are maintaining some old project written in VB6 we are planning to implement continuous integration server for it. We would like to implement some code analysis as well to track that maintanability at least not getting worse. Basically there is only one requirement - the tool should be command line so we can call it from continuous integration server and it should work with VB6 projects. I will really appreciate any recommendations regards tools to try.
Thank you, Maksym
You could look at SourceMonitor as this says that it can produce metrics for VB6, and can be made to work from the command line.
I've only used it for C++ myself.
Have you looked at the recommendations in this question about tools for analysing VB6 source code?
I don't know whether any of these tools can be run from the command-line.
The Code Advisor for Visual Basic 6 is an add-in used to review your code to ensure that it meets predetermined coding standards.
The coding standards are based on best practices developed by Microsoft to produce robust and easy-to-maintain code.
http://www.microsoft.com/en-us/download/details.aspx?id=1222
You can use VBDepend for VB6 and VBA code, static analysis tool based on CQL, here is some of its functionality:
Compare Builds, 60 code metrics, manage Complexity and Dependencies
However VBDepend does not have a rule to check for duplicate/repeated code in the project. This was the most important rule that I was looking for.
Our SD Source Code Search Engine is a tool for lightning-fast search across large code bases.
It words by breaking the text into language atoms, indexing all those atoms, and then executing queries using the indexes to guide the search. The SCSE has a VB6-specific front end (as well as front ends for a wide variety of other languages).
As a side effect of the indexing process, it produces metrics: SLOC, number of comments, Cyclomatic Complexity, Halstead measures, deepest-nested conditionals, etc. These metrics are emitted to an XML file that can be formatted/interrogated any way you like.
The indexing process is a command-line step, so you can integrate it into your scripts.
We also have a clone detector for VB6 that finds exact and near-miss duplicate blocks of code across large systems of source code.
Microsoft has recently put a release of their Code Contracts framework on DevLabs with a commercial license. We're interested on using them in our project (mostly C#, some C++/CLI) to gradually replace all the custom validation code, but I'm keen to know about the experience other people have had with it before we commit to it, specifically:
Do you think the framework is sufficiently mature for large and complex commercial projects?
What problems have you run into while using it?
What benefits have you got from it?
Is it currently more pain than it's worth?
I realise that this is a somewhat subjective question as it requires opinion, but given that this framework is a very significant part of .NET 4.0 and will (potentially) change the way we all write validation code, I hope that this question will be left open to gather experience on the subject to help me make a decision to a specific, answerable question:
Should we be starting to use it next month?
Note that we do not ship a code API, only a web service one, so for the majority of code breaking compatibility in terms of the exception type thrown is not a concern. However, as I'm hoping more people than just me will benefit from this post and its answers, any detail around this area is more than welcome.
The last mature response to this was in 2009, and .NET 4 is out. I figure we're due for an update:
Code Contracts might well be mature enough for your Debug releases.
I realise this is somewhat of an upgrade from “Harmless” to “Mostly Harmless”.
The Code Contracts home page links to quite thorough documentation in PDF format. The documentation outlines usage guidelines in section 5. To summarize, you can pick how brave you feel about the Contract Tools re-writing your IL in your Release builds.
We're using the “don't rewrite my Release IL” mode.
So far, I'm most enjoying this unexpected benefit: there's less code, thus less code to test. All your guard clauses melt away.
if(arg != null) {
throw new ArgumentNullException("arg");
}
// Blank line here insisted upon by StyleCop
becomes:
Contract.Requires(arg != null);
Your functions are shorter. Your intent is clearer. And, you no longer have to write a test named ArgumentShouldNotBeNull just to reach 100% coverage.
So far, I've run into two problems:
I had a unit test which relied on a contract failure to succeed. You might argue the existence of the test was a blunder, but I wanted to document this particular prohibition in the form of a test. The test failed on my build server because I didn't have the tools installed. Solution: install the tools.
We're using two tools that rewrite IL: Code Contracts and PostSharp. They didn't get along too well. PostSharp's 2.0.8.1283 fixed the problem. I'd cautiously evaluate how any two IL-rewriting tools get along, though.
So far, the benefits are outweighing the hazards.
Addressing out-of-date concerns raised in other answers:
Code Contracts's documentation is quite thorough, though regrettably in PDF.
There's at least one Code Contract forum hosted by Microsoft.
Code Contracts Standard Edition is free if you have any VS2010 license.
.NET 4 is out. I've run into Microsoft's contracts when implementing generic collection interfaces.
I've been playing around with the code contracts some more myself on a small but moderately complex standalone project, which needs to inherit from some BCL classes and use other ones.
The contracts thing seems great when you're working in a completely isolated environment with just your own code and primitive types, but as soon as you start using BCL classes (which until .NET 4.0 do not have their own contracts) the verifier cannot check whether they will violate any of the requires/ensures/invariants and so you get a lot of warnings about potentially unsatisfied constraints.
On the other hand, it does find some invalid or potentially unsatisfied constraints which could be real bugs. But it's very hard to find these because there is so much noise that it's hard to find out which ones you can fix. It's possible to suppress the warnings from the BCL classes by using the assume mechanism, but this is somewhat self-defeating as these classes will have contracts in the future and assumptions will lessen their worth.
So my feeling is that for now, because in 3.5 we're trying to build on a framework that the verifier does not sufficiently understand, that it's probably worth waiting for 4.0.
Judging by this thread I would say it is not quite mature enough to use for an enterprise level project. I haven't used it myself, but people are still running into bugs that would bring your contract-critical project to a halt. It seems like a really great framework and the example videos they've provided have been exciting, but I'd wait for:
Existence of a community forum. You're going to want to be able to discuss inevitable problems you run into with other developers, and you want to know there is a decently strong base of developers out there to discuss solutions with.
A successful pilot project release. Generally, when Microsoft Research releases something that they think is mature enough to be used in a commercial project, they will work with an organization to pilot it, and then release that project open source to as a proof of concept and trial-by-fire of all of the major features. This would give a lot of confidence that most of the common contract scenarios are covered and working.
More complete documentation. Plain and simple, at some point you're going to want to do something with contracts that you can't do yet using Microsoft Code Contracts. You want to be able to quickly and clearly reason that your scenario is not yet supported. The current documentation is going to keep you guessing and trying different things, though, in my opinion, which will result in a lot of wasted time.
It's not mature enough.
It will be as soon as Microsoft releases it with the affordable editions of VS, but without the static code analysis it's not usable at all.
The editions of VS, that have it, are so insanely expensive that only a handful of people will ever be able to afford it.
It's a shame Microsoft killed this amazing idea with their pricing policy. I wish Code Contracts would become mainstream, but they won't.
Epic fail.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Is Microsoft Project the best tool for managing software development or IT projects or is there an alternative that is better?
Project is not good for managing development at all. I find it marginally useful for scheduling / work breakdown.
If you're on a Microsoft stack, Team Foundation Server is a good project management solution. It integrates with Project for scheduling and also provides the essentials of source control, work item (task / defect) tracking, and document management (via sharepoint.) The 2008 version has matured nicely, and the 2010 version looks very promising, especially in the area of requirements specification and traceability.
You can replicate the TFS features with a stack of open source and/or less expensive off-the-shelf software, but it is more work to integrate. It's debatable which is more flexible and easier to maintain once set up.
The following are required, regardless of platform:
Bug tracking
Work item / story / progress tracking of some kind (may be managed by above)
Collective team discussion (may be managed by above - discussion on work items, like FogBugz for example)
Source control (anything but SourceSafe)
Continuous build integration that runs unit tests
Instant messaging (OpenFire works great if your network blocks external services)
Document library
Farm of virtualized test machines (especially useful for install/upgrade testing)
I tend to use MSProject for capacity planning - a nice big broad brush of who could do what over a period, at a level of abstraction that makes it easy to rejig plans. For day to day tracking of the real work, I use Fogbugz. I think of it as MSProject/Gantty stuff for the strategic planning, and Fogbugz for the tactical management and planning.
Depends on the process you're using - if it's a waterfall like process, or there's a lot of non-software parts of the project (infrasstructure, manufacturing, marketing etc) then Project's OK for the overall task management - it's certainly competitive with other similar tools.
I don't think any of the "project management" tools (tasks, WBS, gannt charts etc) are much good at the management of the detailed tasks that happen when you're into the main software development phase - I usually end up in Excel for the projects I'm involved in.
And of course, there is much more to the successful management of a non-trivial software project than the bit that can be managed with a tool like Project. It doesn't help much with managing the requirements, issues, defects, meetings, test development etc - but then it's not supposed to.
Because of these limitations, I find I usually get most value out of Project in the planning phase - working out the task breakdown, what needs to be done, and roughly what needs to happen in what order.
As Eisenhower put it: "In preparing for battle I have always found that plans are useless, but planning is indispensable." MS Project is a useful tool for planning.
If also need a free and open alternative to Project, you have OpenProj: http://openproj.org/openproj
We use Target Process here. It has a few "-isms", but overall is a good agile project management tool
We've been successfully using MS Project for planning but were missing the ability to share MS Project plans with customers and colleagues who don't have it installed. This led us to the idea of online Microsoft Project viewer - a service that would allow to view and share MS Project files (.mpp) online, apart from MS Project:
Hope this helps.
We use Acunote at my work place, but we follow a Agile/Scrum methodology.
What constitutes the "best tool" depends on many things. How you run your projects, who will be using them, etc.
There are many better alternatives, at least for software development. One such is embedded in Microsoft Visual Studio Team System. You may also want to check out tools from Rally Software and Version One. The latter are well suited to agile methods, while the former supports both agile and traditional CMM methods.
Well, given the fact that not even the Project team uses Project for Project (Source: Joel Spolsky), I would not want to use it for development.
I track my development tasks in our Bug Tracker, and the Project File just has something like "Planning 1 Week, Development 5 Weeks, QA 3 Weeks, Deployment 1 Week", aka. a VERY broad overview.
As for the BugTracker, FogBugz has this nice Estimate-Tracking that I find quite useful for making schedules, which is for me just another reason to not use Project.
But then again, I am not a Project Manager, so to me, Project is just an unnecessary complex, not really multi-user friendly and somewhat dated-feeling Tool to be used when building Houses, Highways or Space Stations, but not for Software.
We use Primavera on my project. Its supposed to be great although its the only tool I haven't really used for project management so far so I can't really compare it to anything else. Its not that easy to pick up but it can do everything I need (and apparently much more).
My favourite feature is the built in timesheets functionality which means my developers can book their hours to their tasks at the end of the week meaning that I don't need to constantly bug them about how they are progressing against their plans.
personally i dont believe ms project is good for software dev (i have used it, im not bashing it to be a purist)
its great if you are building a house or something which doesnt have such uncontrollable variables (e.g. how many bugs will you have? how long will bugs take to fix? how much feature-creep will there be?)
i like to keep my schedules very simple so more people can understand them, hence why i just use a google spreadsheet
the structure i use is described further here: Project Schedules with Google Spreadsheets
hope this helps
--LM
We are about to get a canned package in that has been modified to our needs. I'm part of the team setup to prepare tests for it. It has an Oracle back end and I believe it's written in C++ .NET.
My question is what free or open source testing tools would you recommend.
Thanks
Ken
For regression testing of our applications I use a free tool called AutoHotKey http://www.autohotkey.com/. It is simple, batch configurable, and can work for virtually any application you have. Not exactly designed for black box testing, but a good free tool to add to your toolbox.
While there are a few good commercial applications for black box testing of applications (HoloDeck http://www.sisecure.com/holodeck/index.shtml, Cenzic Hailstorm http://www.cenzic.com/), the only open source applications that I know about only test network security (Spike http://www.immunitysec.com/resources-freesoftware.shtml, OWASP WebScarab http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project, and Nikto http://www.cirt.net/nikto2)
Value checking. See if only valid dates are exempted, number fields except the full range, ect.
What do you expect from such a tool? I don't know of any tool that can arbitrarily test any piece of software.
For what is sounds like you already know what it is that you want to check. Being a custom application your best bet would be to devise a test plan and manually test the values that you would like to validate.
Agree with the others - since the application has been modified to your needs, you should make sure that it actually is modified to your needs.
If the assembly isn't obfuscated, you can use FxCop to analyze the binaries and see if there are any critical bugs (note - if you're not familiar with fxcop and static analysis, find someone who is before reporting a ton of bugs that won't be fixed).
Beyond that, you're looking at more techniques vs. tools to get the job done.
Testing, either functional or non-functional, without reference to the
internal structure of the component or system.