<p><a href="https://goreportcard.com/" rel="nofollow">https://goreportcard.com/</a> is a way of doing static analysis on your go projects but I feel like it scores way too leniently to be of much use. is there a better tool out there or a way to adjust this tool to be harsher in how it grades projects?</p>
<hr/>**评论：**<br/><br/>hermanschaaf: <pre><p>Author of goreportcard here. It is quite lenient, I agree, and we have discussed improving it, but have not done the work. I filed an issue on Github with an explanation of how the current scoring algorithm works, and a suggestion for how we might change it. Feedback and pull requests welcome! <a href="https://github.com/gojp/goreportcard/issues/98" rel="nofollow">https://github.com/gojp/goreportcard/issues/98</a></p></pre>drvd: <pre><p>Why not just add/subtract x or multiply/divide by y if you think the numbers are wrong?</p></pre>HectorJ: <pre><p>It's not an open scale, it's a %</p>
<p>if you subtract/divide you could end up with negative scores, and would never reach 100%</p>
<p>if you add/multiply, you could end up with scores above 100%</p>
<p>It does not make much sense.</p>
<p>OP seems to want more and stricter criteria</p></pre>drvd: <pre><p>So what? You have to <em>interprete</em> 47% like you would have to interprete -10% or 180%. Such scale are always relative (one project compared to the other) or indicate trends (now worse than 4 weeks ago). Attributing meaning to the number 94% is, well, strange.</p></pre>HectorJ: <pre><p>The main point I should have insisted is actually my last sentence. </p>
<p>Applying a constant to the given results is pointless.</p>
<p>OP wants other criteria </p></pre>drvd: <pre><blockquote>
<p>OP wants other criteria</p>
</blockquote>
<p>I cannot read this from OP's post. But maybe you are right.</p></pre>dankcode: <pre><p>Specifically (& I will comment on the Github issue later) I think that the license should determine pass/fail & not count for the same kind of weight as the cyclo or linting tests. Misspellings should probably be weighted with less importance and i think the cyclo complexity should be dropped to 10 or 5. 15 is really a lot of branching.</p></pre>
