GitHub's a good start but PRs have some non-trivial limitations when it comes to reviewing code efficiently. Tools are springing up to help devs work around the problems without abandoning GitHub. You can take a look at GitColony, Sourcegraph, Review Ninja, and Reviewable (disclosure: this one's mine).
I definitely agree with this (disclosure: I'm Gitcolony's founder). I think that PRs are a great start point but not the best way to review code in a company. I do believe they are great option for open source contributions but not the most efficient one for companies.
+1 on Piotrs comment (disclosure: founding team of ReviewNinja - http://review.ninja). We also found that most users like to put some more structure around their code review and appreciate the fact that tools like the ones mentioned by Piotr give more visibility into outstanding issues that need to be closed, before a pull request can be merged. It is also helpful for most to get a better handling around who 'approved' (+1ed) a PR.
Where I work we use SonarQube [1] for static code analysis. You can customize specific rule profiles for different projects and in the site they say it's available for many programming languages [2]. We only use it for Java so I don't know how good is the support for the other languages listed.
My experience with these tools is that they are a great way to see how the code evolves during a project, help you keep it clean in maintenance mode, and may even teach you a couple of things about good coding practices. Just don't let it fall into the hands of management. They will love all those metrics and graphs, and soon enough you will have goals and performance reviews based on it.
So far I haven't used much manual code review, but I do use static code analysis to find possible bugs once in a while.
Up until recently a big pain point for me was finding code which could block within a time constrained function (aka realtime safety). There weren't any tools out there, so I ended up making one with llvm named stoat[1] (originally static function property verification, sfpv). It's hard to say if this tool would really have wider usefulness as it essentially is just checking function attributes on the transitive closure of the callgraph, but it works for me.
7 comments
[ 2.1 ms ] story [ 27.1 ms ] threadMy experience with these tools is that they are a great way to see how the code evolves during a project, help you keep it clean in maintenance mode, and may even teach you a couple of things about good coding practices. Just don't let it fall into the hands of management. They will love all those metrics and graphs, and soon enough you will have goals and performance reviews based on it.
[1] http://www.sonarqube.org
[2] http://docs.sonarqube.org/display/SONAR/Plugin+Library
Up until recently a big pain point for me was finding code which could block within a time constrained function (aka realtime safety). There weren't any tools out there, so I ended up making one with llvm named stoat[1] (originally static function property verification, sfpv). It's hard to say if this tool would really have wider usefulness as it essentially is just checking function attributes on the transitive closure of the callgraph, but it works for me.
[1] https://github.com/fundamental/stoat