cppcheck plugin for kdevelop available

[Milian Wolff]

On Sunday 17 November 2013 22:19:52 Christoph Thielecke wrote:
> Hello,
> 
> as a kdevelop user I miss the static code analysis integration. Cppcheck
> does a good job.
> 
> I decided to write a plugin which provides this functionality. The cppcheck
> plugin for kdevelop is now available.
> 
> You can find the project page here:
> http://projects.kde.org/projects/playground/devtools/plugins/kdev-cppcheck

Hey Christoph - great work!

In the following I'll give a few remarks on the code:

a) use the ...desktop.cmake & configure_file approach I mentioned on kdevelop@ 
mailing list just now. this way the plugin will properly load for any 
kdevplatform it was compiled against.

b) you should generally depend on a newer kdevplatform, 0.9.96 is not a good 
idea

c) don#t define a default debug area, instead use the new kdebug api to 
register a custom debug area for your plugin.

d) add a cmake_require_minimum(VERSION 2.8) line to your CMakeLists.txt and 
ensure it compiles.

e) use const& for non-POD data, esp. stuff like QString etc. pp.

f) I'd welcome if you could adhere to our coding style guidelines, which is 
basically kdelibs coding style. I know there's lots of different code styles 
in kdev* code, but for new code at least I hope we can approach a common 
denominator. This mostly means puttin *,& to the type, moving opening braces 
directly after conditionals, not on a new line. Also, don't use "this->..." if 
not explictily required to resolve an aliasing with a local variable. Also, 
add braces to all conditionals and loops, even one-liners. Possibly, there are 
more issues.

g) Most, if not all license headers are wrong and reference people other than 
you.

h) Why do you use virtual interfaces, but only implement them once? Do you 
want to extend this in the future? Also, why are the interfaces not pure? 
Generally, I have the feeling that this complicates the code for no gain.

Note that an extensible interface for this should be put into KDevplatform to 
replace our current Problem toolview minus the DUChain coupling. I.e. what I 
mentioned on IRC and added here: 
http://techbase.kde.org/Projects/KDevelop4/GSOCTasks

i) You leak memory, e.g. ui in GenericConfigPage. Use QScopedPointer for that.

j) Don't use NULL, use 0 or go C++11 and use nullptr. Note that we'll require 
C++11 for kdev* 1.7/4.7 so you can do that as well.

k) there's quite some commented-out code - remove that. A VCS keeps it in its 
history for later.

l) you use the <kcmodule.h> style of includes, I'd prefer if you use 
<KCModule> e.g.

m) there's qDebug usage, use kDebug please so the output can be disabled

n) tons of functions are implemented inline. I'd prefer to put everything in 
the .cpp files. If you later spot performance issues which can be improved by 
inlining, then fine. But please do not inline-by-default.

Cheers, that's it for now. And again, good work for writing all this! I hope 
to see more work and eventually a generic checker framework where we can plug 
in more tools like krazy2, clang, valgrind etc. pp.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de