On Thu, 30 Nov 2017 11:48:45 +0100
Stefan Hundhammer
On 30.11.2017 11:14, Josef Reidinger wrote:
Well, advantage against plain rubocop is that it
1. integrate more services - seehttps://docs.codeclimate.com/docs/list-of-engines
Yes, I looked at that, and what Ruby-relevant things I see beyond rubocop is:
- brakeman: checks RAILS apps for security vulnerabilities
We don't use RAILS, so this does not appear to be relevant for us.
- bundler-audit: Find security vulnerabilities in your Ruby dependencies.
I would hope that our security team keeps looking for those things in the entire distribution. Other Ruby development teams outside of SUSE don't have that luxury, so that might really be a plus for them.
- codeclimate-duplication: Tries to find duplicate code. OK, that might be useful if it really works. But the question is if it works across package boundaries, e.g. between one YaST package and others. I am doubtful about that.
There is also reek one (in second table), which have some interesting checks - https://github.com/troessner/reek . It can be also configured to track your test coverage ( so it can be used instead of coveralls )
2. visualize it
https://codeclimate.com/github/yast/yast-storage-ng
Is that it, or is there more?
well, it shows - proportion of ratings of files ( so you know if there is few bad files and rest is good, or bunch of average rated files ) - there are summary - there are trends in three dimensions ( e.g. churn one is interesting, also remaining ones ) - there are list of issues - there are progress report so you see what changes during last month - there are overview of per file ratings - it is connected together, so you can easily click thrue it ( not so easy for rubocop on CLI ) What do you missing here in visualization?
3. have rating, so it is not plain pass/fail, but allow to see something like worse, but still not above limit.
https://codeclimate.com/github/yast/yast-storage-ng https://codeclimate.com/github/yast/yast-installation https://codeclimate.com/github/yast/yast-network
Hm...
Sorry, I have not mind reader. I have no idea what you dislike here.
4. provides badge for project, so it shows external people some idea about code quality
If it's badges we are after, I can offer you as many as you like - colored, black and white, whatever.
But I am not sure how many users and customers care about that. As Arvin mentioned, the number and severity of bugs and our response time for a first reaction and until a fix is released will matter a lot more to them. But none of that is something we make easily accessible to the public.
Badges are not for users nor customers. It is for external contributors to get idea about project state like code quality, test coverage, documentation coverage quickly. It is current trend for public project to show quickly its state. See e.g. trending projects on github like: https://github.com/antvis/g2 https://github.com/tldr-pages/tldr So we can be dinosaur like COBOL and avoid any trends and changes and become legacy that no-one wanted to touch. Or we can try to look around, adapt to trends and try to attract some attention.
Just my 2 Cents.
Kind regards
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org