3 ms·

The most important part of a code review is the why, not the how. It's pretty easy to implement pre-commit checks that would validate and enforce style and cer

by eliben 11y ago

The most important part of a code review is the why, not the how. It's pretty easy to implement pre-commit checks that would validate and enforce style and certain lint checks - many companies have these. No automatic check will make sure that the right problem is being solved with the right approach, though.

dkhenry 11y ago
Having never used this specific product I can't makes claims about any of its functionality, but what I have found is the gap between what one _can_ do, and what people _do_ is very very large. Yeah you can implement all this yourself using pre commit hooks, but do you ? Right now you could pay a little money and vastly improve the quality of your code base. There is value to be added by getting a packaged version of something and having it just work.
- ThePhysicist 11y ago
  Good point! When asking developers about their use of static code analysis to ensure code quality we found that most development teams use such tools only sporadically or not at all, and just very few teams have a systematic process or set of guidelines for ensuring code quality throughout all of their projects. So while some technologies already exist for this, we definitely think that there's room for more.
  - gknoy 11y ago
    I'm not a fan of pre-commit hooks (as I'd rather write it, lint it, fix-rebase-it), but I love having a CI suite that includes the linting tests that our team has agreed on. It lets me code away and lint things when I'm ready to make my pull requests.
    - jquast 11y ago
      agreed, git hooks are a terrible place, they can actually impede progress and can also be skipped/disabled/never installed in the first place. The time for rejecting a build for linting is at time of merge to trunk/next release, which a good CI should already have checked.
    - ThePhysicist 11y ago
      yeah that's the workflow we have in mind as well: -make changes in a feature branch -have the linter run on each commit to see if there are problems -when you make a pull request, check the code again and comment on the PR if there are any problems.
ThePhysicist 11y ago
Co-founder here! That's a valid point of course and I agree that it's hard to check for the "why" using automated tools and without prior knowledge of the programmers intentions. However, it is absolutely possible to take your own idea of "good code" and translate it to a set of custom code checking rules in our tool, which you can then enforce automatically throughout all of your projects. So as long as you know what "good code" is for you and how it should look you can automate the checking. You can also share your own code patterns with other users btw so that they can use them in their projects, and you can use rules created by other users. Crowd-sourced code quality so to say :) Feedback is highly welcome btw since it's still a pretty early version of our product, so if you have comments, bug reports, suggestions or feature requests feel free to get in touch with us (@quantifiedcode, andreas@quantifiedcode.com)

by eliben 11y ago

dkhenry 11y ago

Having never used this specific product I can't makes claims about any of its functionality, but what I have found is the gap between what one _can_ do, and what people _do_ is very very large. Yeah you can implement all this yourself using pre commit hooks, but do you ? Right now you could pay a little money and vastly improve the quality of your code base. There is value to be added by getting a packaged version of something and having it just work.

ThePhysicist 11y ago
Good point! When asking developers about their use of static code analysis to ensure code quality we found that most development teams use such tools only sporadically or not at all, and just very few teams have a systematic process or set of guidelines for ensuring code quality throughout all of their projects. So while some technologies already exist for this, we definitely think that there's room for more.
- gknoy 11y ago
  I'm not a fan of pre-commit hooks (as I'd rather write it, lint it, fix-rebase-it), but I love having a CI suite that includes the linting tests that our team has agreed on. It lets me code away and lint things when I'm ready to make my pull requests.
  - jquast 11y ago
    agreed, git hooks are a terrible place, they can actually impede progress and can also be skipped/disabled/never installed in the first place. The time for rejecting a build for linting is at time of merge to trunk/next release, which a good CI should already have checked.
  - ThePhysicist 11y ago
    yeah that's the workflow we have in mind as well: -make changes in a feature branch -have the linter run on each commit to see if there are problems -when you make a pull request, check the code again and comment on the PR if there are any problems.

ThePhysicist 11y ago

Co-founder here! That's a valid point of course and I agree that it's hard to check for the "why" using automated tools and without prior knowledge of the programmers intentions. However, it is absolutely possible to take your own idea of "good code" and translate it to a set of custom code checking rules in our tool, which you can then enforce automatically throughout all of your projects. So as long as you know what "good code" is for you and how it should look you can automate the checking. You can also share your own code patterns with other users btw so that they can use them in their projects, and you can use rules created by other users. Crowd-sourced code quality so to say :) Feedback is highly welcome btw since it's still a pretty early version of our product, so if you have comments, bug reports, suggestions or feature requests feel free to get in touch with us (@quantifiedcode, andreas@quantifiedcode.com)