From dcd71ddd69d17b057288a313e580658ba7885b9b Mon Sep 17 00:00:00 2001 From: Dusan Orlovic Date: Wed, 23 Aug 2023 08:40:41 +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 f5a96a1..0287a9e 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-(2018)") 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