cppcheck plugin for kdevelop available
mail at milianw.de
Mon Nov 18 16:18:09 UTC 2013
On Sunday 17 November 2013 22:19:52 Christoph Thielecke wrote:
> 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:
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
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
g) Most, if not all license headers are wrong and reference people other than
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:
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
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.
mail at milianw.de
More information about the KDevelop-devel