From f7a57d9d95e4af2f98150ecfece2432d45b61d3f Mon Sep 17 00:00:00 2001 From: Dusan Orlovic Date: Wed, 23 Aug 2023 08:40:21 +0200 Subject: [PATCH] Updated How to do Code Reviews (markdown) --- How-to-do-Code-Reviews.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/How-to-do-Code-Reviews.md b/How-to-do-Code-Reviews.md index 1e8886d..f5a96a1 100644 --- a/How-to-do-Code-Reviews.md +++ b/How-to-do-Code-Reviews.md @@ -4,7 +4,7 @@ Things you should verify as you code review a PR: * Make sure [I18n](Internationalisation-%28i18n%29) best practices are followed * Make sure [the build](Continuous-Integration) for the PR is green * Make sure the changes are tested at appropriate level (see [rspec tips](Testing-and-Rspec-Tips) and [karma tips](Karma) for help) -* Make sure tech [best practices](Code,-the-way-we-do-things) are being followed +* Make sure tech [best practices]("Code,-the-way-we-do-things-(2018)") are being followed * Focus on the implications, design, readability and complexity of the change rather than only its syntax. The latter is what machines are meant to do and that's why we use [Rubocop](http://batsov.com/rubocop/). * Make sure [code conventions](https://github.com/openfoodfoundation/openfoodnetwork/wiki/Code-Conventions) are followed (things [Rubocop](http://batsov.com/rubocop/) doesn't check) * Make sure the boy scout rule is applied: when changing code, it's important to respect the existing structure, but it's even better when we refactor on the way and improve the code we are changing. \ No newline at end of file