Topic Any plans to run static-analysis on the code?
This board is threaded (i.e. has a tree structure). Please use the Reply button of the specific post you are referring to, not just any random button. If you want to reply to the topic in general, use the Post button near the top and bottom of the page.
In Response to Sven2
Hi Anonymous,
thanks for looking into the OpenClonk project! Static analysis is actually already done by the autobuilds. For example, here is the output of the latest Windows build:
https://autobuild.openclonk.org/builds/3d91671d-44fb-4634-b206-c36a6a876a7c/
The warnings about unused variables are visible in yellow; the places you mentioned are already there. Personally, I would love to be warning-free (and turn off warnings that don't make sense / we don't intend to react to), so each new warning can be checked immediately. Unfortunately, noone works on that for now. If you want to provide a patch, please go ahead! It's usually posted as a pull request on github and then advertised here.
The 0 versus nullptr is probably a good change. I'm not sure about the "auto" versus "int32_t", but don't care too much either way. Using range-based for everywhere also sounds like a pretty tiresome change. Particularly because we use some non-STL container classes in some places that do not support this kind of loop (yet).
thanks for looking into the OpenClonk project! Static analysis is actually already done by the autobuilds. For example, here is the output of the latest Windows build:
https://autobuild.openclonk.org/builds/3d91671d-44fb-4634-b206-c36a6a876a7c/
The warnings about unused variables are visible in yellow; the places you mentioned are already there. Personally, I would love to be warning-free (and turn off warnings that don't make sense / we don't intend to react to), so each new warning can be checked immediately. Unfortunately, noone works on that for now. If you want to provide a patch, please go ahead! It's usually posted as a pull request on github and then advertised here.
The 0 versus nullptr is probably a good change. I'm not sure about the "auto" versus "int32_t", but don't care too much either way. Using range-based for everywhere also sounds like a pretty tiresome change. Particularly because we use some non-STL container classes in some places that do not support this kind of loop (yet).
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill