├── CONTRIBUTING.md ├── LICENSE ├── README.md ├── appendix ├── checkpoint-review-process.md ├── gitworkflow.png └── integrations.png ├── behavioural-practices └── README.md ├── best-practices └── README.md ├── code-performance └── README.md ├── coding-style-guides └── README.md ├── getting-started └── README.md ├── quality-checks └── README.md └── style └── ruby └── sample.rb /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | If you have something you want to add or remove, please open a new pull request. 3 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | GNU GENERAL PUBLIC LICENSE 2 | Version 2, June 1991 3 | 4 | Copyright (C) 1989, 1991 Free Software Foundation, Inc., 5 | 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA 6 | Everyone is permitted to copy and distribute verbatim copies 7 | of this license document, but changing it is not allowed. 8 | 9 | Preamble 10 | 11 | The licenses for most software are designed to take away your 12 | freedom to share and change it. By contrast, the GNU General Public 13 | License is intended to guarantee your freedom to share and change free 14 | software--to make sure the software is free for all its users. This 15 | General Public License applies to most of the Free Software 16 | Foundation's software and to any other program whose authors commit to 17 | using it. (Some other Free Software Foundation software is covered by 18 | the GNU Lesser General Public License instead.) You can apply it to 19 | your programs, too. 20 | 21 | When we speak of free software, we are referring to freedom, not 22 | price. Our General Public Licenses are designed to make sure that you 23 | have the freedom to distribute copies of free software (and charge for 24 | this service if you wish), that you receive source code or can get it 25 | if you want it, that you can change the software or use pieces of it 26 | in new free programs; and that you know you can do these things. 27 | 28 | To protect your rights, we need to make restrictions that forbid 29 | anyone to deny you these rights or to ask you to surrender the rights. 30 | These restrictions translate to certain responsibilities for you if you 31 | distribute copies of the software, or if you modify it. 32 | 33 | For example, if you distribute copies of such a program, whether 34 | gratis or for a fee, you must give the recipients all the rights that 35 | you have. You must make sure that they, too, receive or can get the 36 | source code. And you must show them these terms so they know their 37 | rights. 38 | 39 | We protect your rights with two steps: (1) copyright the software, and 40 | (2) offer you this license which gives you legal permission to copy, 41 | distribute and/or modify the software. 42 | 43 | Also, for each author's protection and ours, we want to make certain 44 | that everyone understands that there is no warranty for this free 45 | software. If the software is modified by someone else and passed on, we 46 | want its recipients to know that what they have is not the original, so 47 | that any problems introduced by others will not reflect on the original 48 | authors' reputations. 49 | 50 | Finally, any free program is threatened constantly by software 51 | patents. We wish to avoid the danger that redistributors of a free 52 | program will individually obtain patent licenses, in effect making the 53 | program proprietary. To prevent this, we have made it clear that any 54 | patent must be licensed for everyone's free use or not licensed at all. 55 | 56 | The precise terms and conditions for copying, distribution and 57 | modification follow. 58 | 59 | GNU GENERAL PUBLIC LICENSE 60 | TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 61 | 62 | 0. This License applies to any program or other work which contains 63 | a notice placed by the copyright holder saying it may be distributed 64 | under the terms of this General Public License. The "Program", below, 65 | refers to any such program or work, and a "work based on the Program" 66 | means either the Program or any derivative work under copyright law: 67 | that is to say, a work containing the Program or a portion of it, 68 | either verbatim or with modifications and/or translated into another 69 | language. (Hereinafter, translation is included without limitation in 70 | the term "modification".) Each licensee is addressed as "you". 71 | 72 | Activities other than copying, distribution and modification are not 73 | covered by this License; they are outside its scope. The act of 74 | running the Program is not restricted, and the output from the Program 75 | is covered only if its contents constitute a work based on the 76 | Program (independent of having been made by running the Program). 77 | Whether that is true depends on what the Program does. 78 | 79 | 1. You may copy and distribute verbatim copies of the Program's 80 | source code as you receive it, in any medium, provided that you 81 | conspicuously and appropriately publish on each copy an appropriate 82 | copyright notice and disclaimer of warranty; keep intact all the 83 | notices that refer to this License and to the absence of any warranty; 84 | and give any other recipients of the Program a copy of this License 85 | along with the Program. 86 | 87 | You may charge a fee for the physical act of transferring a copy, and 88 | you may at your option offer warranty protection in exchange for a fee. 89 | 90 | 2. You may modify your copy or copies of the Program or any portion 91 | of it, thus forming a work based on the Program, and copy and 92 | distribute such modifications or work under the terms of Section 1 93 | above, provided that you also meet all of these conditions: 94 | 95 | a) You must cause the modified files to carry prominent notices 96 | stating that you changed the files and the date of any change. 97 | 98 | b) You must cause any work that you distribute or publish, that in 99 | whole or in part contains or is derived from the Program or any 100 | part thereof, to be licensed as a whole at no charge to all third 101 | parties under the terms of this License. 102 | 103 | c) If the modified program normally reads commands interactively 104 | when run, you must cause it, when started running for such 105 | interactive use in the most ordinary way, to print or display an 106 | announcement including an appropriate copyright notice and a 107 | notice that there is no warranty (or else, saying that you provide 108 | a warranty) and that users may redistribute the program under 109 | these conditions, and telling the user how to view a copy of this 110 | License. (Exception: if the Program itself is interactive but 111 | does not normally print such an announcement, your work based on 112 | the Program is not required to print an announcement.) 113 | 114 | These requirements apply to the modified work as a whole. If 115 | identifiable sections of that work are not derived from the Program, 116 | and can be reasonably considered independent and separate works in 117 | themselves, then this License, and its terms, do not apply to those 118 | sections when you distribute them as separate works. But when you 119 | distribute the same sections as part of a whole which is a work based 120 | on the Program, the distribution of the whole must be on the terms of 121 | this License, whose permissions for other licensees extend to the 122 | entire whole, and thus to each and every part regardless of who wrote it. 123 | 124 | Thus, it is not the intent of this section to claim rights or contest 125 | your rights to work written entirely by you; rather, the intent is to 126 | exercise the right to control the distribution of derivative or 127 | collective works based on the Program. 128 | 129 | In addition, mere aggregation of another work not based on the Program 130 | with the Program (or with a work based on the Program) on a volume of 131 | a storage or distribution medium does not bring the other work under 132 | the scope of this License. 133 | 134 | 3. You may copy and distribute the Program (or a work based on it, 135 | under Section 2) in object code or executable form under the terms of 136 | Sections 1 and 2 above provided that you also do one of the following: 137 | 138 | a) Accompany it with the complete corresponding machine-readable 139 | source code, which must be distributed under the terms of Sections 140 | 1 and 2 above on a medium customarily used for software interchange; or, 141 | 142 | b) Accompany it with a written offer, valid for at least three 143 | years, to give any third party, for a charge no more than your 144 | cost of physically performing source distribution, a complete 145 | machine-readable copy of the corresponding source code, to be 146 | distributed under the terms of Sections 1 and 2 above on a medium 147 | customarily used for software interchange; or, 148 | 149 | c) Accompany it with the information you received as to the offer 150 | to distribute corresponding source code. (This alternative is 151 | allowed only for noncommercial distribution and only if you 152 | received the program in object code or executable form with such 153 | an offer, in accord with Subsection b above.) 154 | 155 | The source code for a work means the preferred form of the work for 156 | making modifications to it. For an executable work, complete source 157 | code means all the source code for all modules it contains, plus any 158 | associated interface definition files, plus the scripts used to 159 | control compilation and installation of the executable. However, as a 160 | special exception, the source code distributed need not include 161 | anything that is normally distributed (in either source or binary 162 | form) with the major components (compiler, kernel, and so on) of the 163 | operating system on which the executable runs, unless that component 164 | itself accompanies the executable. 165 | 166 | If distribution of executable or object code is made by offering 167 | access to copy from a designated place, then offering equivalent 168 | access to copy the source code from the same place counts as 169 | distribution of the source code, even though third parties are not 170 | compelled to copy the source along with the object code. 171 | 172 | 4. You may not copy, modify, sublicense, or distribute the Program 173 | except as expressly provided under this License. Any attempt 174 | otherwise to copy, modify, sublicense or distribute the Program is 175 | void, and will automatically terminate your rights under this License. 176 | However, parties who have received copies, or rights, from you under 177 | this License will not have their licenses terminated so long as such 178 | parties remain in full compliance. 179 | 180 | 5. You are not required to accept this License, since you have not 181 | signed it. However, nothing else grants you permission to modify or 182 | distribute the Program or its derivative works. These actions are 183 | prohibited by law if you do not accept this License. Therefore, by 184 | modifying or distributing the Program (or any work based on the 185 | Program), you indicate your acceptance of this License to do so, and 186 | all its terms and conditions for copying, distributing or modifying 187 | the Program or works based on it. 188 | 189 | 6. Each time you redistribute the Program (or any work based on the 190 | Program), the recipient automatically receives a license from the 191 | original licensor to copy, distribute or modify the Program subject to 192 | these terms and conditions. You may not impose any further 193 | restrictions on the recipients' exercise of the rights granted herein. 194 | You are not responsible for enforcing compliance by third parties to 195 | this License. 196 | 197 | 7. If, as a consequence of a court judgment or allegation of patent 198 | infringement or for any other reason (not limited to patent issues), 199 | conditions are imposed on you (whether by court order, agreement or 200 | otherwise) that contradict the conditions of this License, they do not 201 | excuse you from the conditions of this License. If you cannot 202 | distribute so as to satisfy simultaneously your obligations under this 203 | License and any other pertinent obligations, then as a consequence you 204 | may not distribute the Program at all. For example, if a patent 205 | license would not permit royalty-free redistribution of the Program by 206 | all those who receive copies directly or indirectly through you, then 207 | the only way you could satisfy both it and this License would be to 208 | refrain entirely from distribution of the Program. 209 | 210 | If any portion of this section is held invalid or unenforceable under 211 | any particular circumstance, the balance of the section is intended to 212 | apply and the section as a whole is intended to apply in other 213 | circumstances. 214 | 215 | It is not the purpose of this section to induce you to infringe any 216 | patents or other property right claims or to contest validity of any 217 | such claims; this section has the sole purpose of protecting the 218 | integrity of the free software distribution system, which is 219 | implemented by public license practices. Many people have made 220 | generous contributions to the wide range of software distributed 221 | through that system in reliance on consistent application of that 222 | system; it is up to the author/donor to decide if he or she is willing 223 | to distribute software through any other system and a licensee cannot 224 | impose that choice. 225 | 226 | This section is intended to make thoroughly clear what is believed to 227 | be a consequence of the rest of this License. 228 | 229 | 8. If the distribution and/or use of the Program is restricted in 230 | certain countries either by patents or by copyrighted interfaces, the 231 | original copyright holder who places the Program under this License 232 | may add an explicit geographical distribution limitation excluding 233 | those countries, so that distribution is permitted only in or among 234 | countries not thus excluded. In such case, this License incorporates 235 | the limitation as if written in the body of this License. 236 | 237 | 9. The Free Software Foundation may publish revised and/or new versions 238 | of the General Public License from time to time. Such new versions will 239 | be similar in spirit to the present version, but may differ in detail to 240 | address new problems or concerns. 241 | 242 | Each version is given a distinguishing version number. If the Program 243 | specifies a version number of this License which applies to it and "any 244 | later version", you have the option of following the terms and conditions 245 | either of that version or of any later version published by the Free 246 | Software Foundation. If the Program does not specify a version number of 247 | this License, you may choose any version ever published by the Free Software 248 | Foundation. 249 | 250 | 10. If you wish to incorporate parts of the Program into other free 251 | programs whose distribution conditions are different, write to the author 252 | to ask for permission. For software which is copyrighted by the Free 253 | Software Foundation, write to the Free Software Foundation; we sometimes 254 | make exceptions for this. Our decision will be guided by the two goals 255 | of preserving the free status of all derivatives of our free software and 256 | of promoting the sharing and reuse of software generally. 257 | 258 | NO WARRANTY 259 | 260 | 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY 261 | FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN 262 | OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES 263 | PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED 264 | OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 265 | MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS 266 | TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE 267 | PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, 268 | REPAIR OR CORRECTION. 269 | 270 | 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING 271 | WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR 272 | REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, 273 | INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING 274 | OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED 275 | TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY 276 | YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 277 | PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE 278 | POSSIBILITY OF SUCH DAMAGES. 279 | 280 | END OF TERMS AND CONDITIONS 281 | 282 | How to Apply These Terms to Your New Programs 283 | 284 | If you develop a new program, and you want it to be of the greatest 285 | possible use to the public, the best way to achieve this is to make it 286 | free software which everyone can redistribute and change under these terms. 287 | 288 | To do so, attach the following notices to the program. It is safest 289 | to attach them to the start of each source file to most effectively 290 | convey the exclusion of warranty; and each file should have at least 291 | the "copyright" line and a pointer to where the full notice is found. 292 | 293 | {description} 294 | Copyright (C) {year} {fullname} 295 | 296 | This program is free software; you can redistribute it and/or modify 297 | it under the terms of the GNU General Public License as published by 298 | the Free Software Foundation; either version 2 of the License, or 299 | (at your option) any later version. 300 | 301 | This program is distributed in the hope that it will be useful, 302 | but WITHOUT ANY WARRANTY; without even the implied warranty of 303 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 304 | GNU General Public License for more details. 305 | 306 | You should have received a copy of the GNU General Public License along 307 | with this program; if not, write to the Free Software Foundation, Inc., 308 | 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 309 | 310 | Also add information on how to contact you by electronic and paper mail. 311 | 312 | If the program is interactive, make it output a short notice like this 313 | when it starts in an interactive mode: 314 | 315 | Gnomovision version 69, Copyright (C) year name of author 316 | Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. 317 | This is free software, and you are welcome to redistribute it 318 | under certain conditions; type `show c' for details. 319 | 320 | The hypothetical commands `show w' and `show c' should show the appropriate 321 | parts of the General Public License. Of course, the commands you use may 322 | be called something other than `show w' and `show c'; they could even be 323 | mouse-clicks or menu items--whatever suits your program. 324 | 325 | You should also get your employer (if you work as a programmer) or your 326 | school, if any, to sign a "copyright disclaimer" for the program, if 327 | necessary. Here is a sample; alter the names: 328 | 329 | Yoyodyne, Inc., hereby disclaims all copyright interest in the program 330 | `Gnomovision' (which makes passes at compilers) written by James Hacker. 331 | 332 | {signature of Ty Coon}, 1 April 1989 333 | Ty Coon, President of Vice 334 | 335 | This General Public License does not permit incorporating your program into 336 | proprietary programs. If your program is a subroutine library, you may 337 | consider it more useful to permit linking proprietary applications with the 338 | library. If this is what you want to do, use the GNU Lesser General 339 | Public License instead of this License. 340 | 341 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ![Andela Logo](https://avatars3.githubusercontent.com/u/4100206?v=3&s=100) 2 | # Code Review Guidelines 3 | The purpose of this guide is to define standards for all code reviews done by Trainers in Andela and also ensure that code written by Andela fellows are top notch and excellent. These guidelines are to be applied for checkpoint assessments as well as regular day to day code reviews performed in your role as Senior Engineer. 4 | 5 | As a Senior Engineer, code review is one of the most important aspects of what you do and doing it right is instrumental to grooming the right type of engineers and writing effective code in general. 6 | 7 | Most of the information provided in this document was adopted from the [thoughtbot Code Review Guide](https://github.com/thoughtbot/guides/tree/master/code-review). 8 | 9 | ## Table of Contents 10 | - [Behavioural Practices for Reviewers and Reviewees](http://github.com/andela/code-review-guidelines/blob/master/behavioural-practices) 11 | - [Before you start reviewing](http://github.com/andela/code-review-guidelines/blob/master/getting-started) 12 | - [Initial Code Quality Checks](http://github.com/andela/code-review-guidelines/blob/master/quality-checks) 13 | - [Coding Style Guides](http://github.com/andela/code-review-guidelines/blob/master/coding-style-guides) 14 | - [Best Practices](http://github.com/andela/code-review-guidelines/blob/master/best-practices) 15 | - [Code Performance](http://github.com/andela/code-review-guidelines/blob/master/code-performance) 16 | 17 | ## Contributing 18 | Please read the [contribution guidelines](http://github.com/andela/code-review-guidelines/blob/master/CONTRIBUTING.md) before submitting a pull request. 19 | -------------------------------------------------------------------------------- /appendix/checkpoint-review-process.md: -------------------------------------------------------------------------------- 1 | # Checkpoint Submission Process 2 | Version 2.0 3 | 4 | #### Git *Workflow* 5 | 6 | This is the recommended Git *workflow* to enable easy review: 7 | 8 | - First create the checkpoint repository on your Github account. 9 | - Clone the repository on your local machine. 10 | - At this point, your will only be having one branch (master), create a new branch (develop) off master branch. 11 | - All your work should done on the **develop** branch. 12 | - On Github, create a Pull Request: 13 | * Subject: **Checkpoint Review** 14 | * Description: **write a summary of what you’ve done and your approach.** 15 | - This will make it easy for the reviewer to comment through your code at one glance as opposed to moving in between your commits. See sample below: 16 | 17 | ![Github](https://raw.githubusercontent.com/andela-mkwamboka/code-review-guidelines/master/appendix/gitworkflow.png) 18 | 19 | 20 | #### Integrations 21 | 22 | The following 3 integrations **must** be on your repository: 23 | 24 | - Tests, we recommend any of the following: 25 | * [TravisCI](https://travis-ci.org/) 26 | * [CircleCI](http://circleci.com/) 27 | - Test Coverage, we recommend: 28 | * [Coveralls](https://coveralls.io/) 29 | * [CodeClimate](https://codeclimate.com/) (combined Test Coverage and Code Quality) 30 | - Code Quality, we recommend any of the following: 31 | * [Scrutinizer](https://coveralls.io/) (Ruby, Python, PHP) 32 | * [Landscape](https://landscape.io/) (Python) 33 | * [QuantifiedCode](https://www.quantifiedcode.com/) (Python) 34 | * [StyleCI](https://styleci.io/) (PHP) 35 | * [HoundCI](https://houndci.com/) (JavaScript, Swift) 36 | - Then include the badges for your integration on the README, e.g. 37 | 38 | ![Integrations](https://raw.githubusercontent.com/andela-mkwamboka/code-review-guidelines/master/appendix/integrations.png) 39 | 40 | #### Functionality checks 41 | 42 | The following 3 integrations **must** be on your repository: 43 | 44 | - Check and double check your functionality. You can schedule time during my office hours to talk about your progress and how you can improve on what you’re currently doing. 45 | - Reach out to your colleagues to help you review your app’s functionality and code. **Ensure you’ve gotten at least 2 other people to look at and critique your work.** 46 | * Will be good for comments to be given alongside a PR file diff for documentation. 47 | - Double check against the requirements. Ensure you are meeting all the requirements for the CP. Edge cases, Catching errors properly, UI considerations, etc. 48 | 49 | 50 | 51 | #### Demo 52 | 53 | After you’re sure that your work is solid. Go ahead and record a video of your functionality. Ensure you are audible, clear and straight to the point. Your video should be 5mins or less. Adding extra swagu to the video is a plus. For command line applications, you can use asciinema (See sample [here](https://asciinema.org/a/ecf1yzu8gvhiwwtg5ry4fuoil)) and for other applications, you can use Quicktime. 54 | 55 | 56 | #### Request for Defense 57 | 58 | Send an email to your trainer, with the subject line **Checkpoint Submission** 59 | The email should contain your Github repo, URL of the app and a link to the application demo video. 60 | 61 | The trainer will then reply this e-mail with comments or next steps. If all is good, you will be asked to schedule a defence/code review. 62 | 63 | 64 | #### Defense Session 65 | 66 | During the defence/code review, you will walk your trainer through your code (this should be thorough and you should talk about interesting techniques used, tools you leveraged on, etc). This is the final stage of checkpoint submission and afterwards, if there are still minor things that need to be fixed, this will be addressed via comments on your Github repo or direct messages via Slack. 67 | 68 | -------------------------------------------------------------------------------- /appendix/gitworkflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/andela/code-review-guidelines/d5646f2b3a2b9fe51b5338df7b7006c6e3d8a674/appendix/gitworkflow.png -------------------------------------------------------------------------------- /appendix/integrations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/andela/code-review-guidelines/d5646f2b3a2b9fe51b5338df7b7006c6e3d8a674/appendix/integrations.png -------------------------------------------------------------------------------- /behavioural-practices/README.md: -------------------------------------------------------------------------------- 1 | ## Behavioural Practices for Reviewer and Reviewee 2 | - Accept that many programming decisions are opinions. Discuss tradeoffs, which you prefer, and reach a resolution quickly. 3 | - Ask questions; don't make demands. ("What do you think about naming this :user_id?"). A typical example would be if someone were using multiple for loops to perform an array intersection. A bad thing to say would be, “Hey, learn lodash!” or “Use lodash”, while a good thing to say would be, “What do you think about implementing this array intersection using the intersect function in lodash?”. This way we present it more as a suggestion as opposed to a demand. 4 | - Ask for clarification. ("I didn't understand. Can you clarify?"). This will mostly be the case in project code reviews. 5 | - Avoid selective ownership of code. ("mine", "not mine", "yours") [Project Code Review Specific] 6 | - Avoid using terms that could be seen as referring to personal traits. ("dumb", "stupid"). Assume everyone is intelligent, and well-meaning. 7 | - Be explicit. Remember people don't always understand your intentions online. 8 | - Be humble. ("I'm not sure - let's look it up.") 9 | - Don't use exaggerated terms. ("always", "never", "endlessly", "nothing") 10 | - Don't use sarcasm. 11 | - Keep it real. If emoji, animated gifs, or humor aren't you, don't force them. If they are, use them with aplomb. 12 | - Talk in person if there are too many "I didn't understand" or "Alternative solution:" comments. Post a follow-up comment summarizing offline discussion. 13 | 14 | ## For the reviewer 15 | Understand why the code is necessary (bug, user experience, refactoring). Then: 16 | - Seek to understand the author's perspective. 17 | - Communicate which ideas you feel strongly about and those you don't. 18 | - Identify ways to simplify the code while still solving the problem. 19 | - If discussions turn too philosophical or academic, move the discussion offline to during pairing sessions/office hours or initiate an in-person conversation. In the meantime, let the author make the final decision on alternative implementations. 20 | - Offer alternative implementations, but assume the author already considered them. ("What do you think about using a custom validator here?"). Always favour asking questions over making demand. 21 | - When trying to offer alternative solutions, always link to resources if possible to help ensure that the claims being raised are validated. 22 | - It’s OK to say it’s all good. 23 | -------------------------------------------------------------------------------- /best-practices/README.md: -------------------------------------------------------------------------------- 1 | # General best practices 2 | Writing code to follow best practices is at the heart of good coding practice. We have highlighted below a few of the things you would need to look out for when reviewing code. 3 | 4 | - **DRY (Don’t Repeat Yourself)** 5 | Code should be DRY. Just like earlier mentioned, you need to ask the question “Is there redundant or duplicate code?”. Ensure that unnecessary repetitions don’t exist within the code base. 6 | 7 | - **Object Oriented Programming** 8 | Follow [SOLID principles](http://code.tutsplus.com/series/the-solid-principles--cms-634) for writing object oriented programs. At the very least, we should ensure that programs have high cohesion and loose coupling. 9 | 10 | - **Documenting Code** 11 | Code is expected to be thoroughly documented. Always use doc style comments if possible but also write code in a way that you may require little or no comments. 12 | 13 | - **Separation of Concerns** 14 | Technically, you could write an entire application code within a single file. But that would prove to be a nightmare to read and maintain. Ensure that your code is always broken into logical containers, properly arranged within folders. This makes it far easier to navigate through your codebase. 15 | 16 | As a general rule of thumb, ensure the reviewee is writing the kind of code YOU can ship as your own. 17 | 18 | (TODO: Language Specific best practices) 19 | -------------------------------------------------------------------------------- /code-performance/README.md: -------------------------------------------------------------------------------- 1 | # Code Performance 2 | We need to be observing things that can possibly make a program slow or perform sub-optimally in production. Things to watch out for include the following: 3 | 4 | - **Complexity** - Watch out for nested for loops. It’s not always a bad thing but see if there are ways to refactor code like this to be less complex. It is important to create an awareness in the reviewee to always look for ways to optimize the running time of their code. 5 | - **Efficiency** - Encourage the use of better data structures or faster algorithms to solve problems. A typical example of this would be using a dictionary for grouped data instead of using multiple lists or declaring unnecessary variables. 6 | - **Memory management** - Instill a mindset in the reviewee to always think about ways to optimize memory usage in their code. An Android Developer for instance should be encouraged as much as possible to ensure to cleanup afterwards to ensure there are no unused variables and memory leaks. Scenarios? 7 | - **Design Patterns** - Design patterns besides being accepted ways of solving repetitive problems can also lead to more efficient programs in terms of time and space. Wherever applicable, ensure reviewees are applying design patterns to solve general repetitive problems. _Examples?_ -------------------------------------------------------------------------------- /coding-style-guides/README.md: -------------------------------------------------------------------------------- 1 | # Coding Style Guides 2 | Writing readable code is an art and following style guides is one way of ensuring our code is always clean, readable and consistent. Language specific style guides exist but general coding standards apply to all programming languages. 3 | These are not to be blindly followed; strive to understand these and ask when in doubt. 4 | 5 | **General** 6 | - Don't duplicate the functionality of a built-in library (Note that this is not the case if the task at hand is purely algorithmic). 7 | - Don't swallow exceptions or "fail silently". 8 | - Don't write code that guesses at future functionality. 9 | - Exceptions should be exceptional. 10 | 11 | **Naming** 12 | - Make use of meaningful variable names. Avoid abbreviations. 13 | - Avoid object types in names (`user_array`, `email_method`, `CalculatorClass`, `ReportModule`). 14 | - Prefer naming classes after domain concepts rather than patterns they implement (e.g. `Guest` vs `NullUser`, `CachedRequest` vs `RequestDecorator`). 15 | - Name the enumeration parameter the singular of the collection. e.g when looping over a collection of books, say for book in books and not for b in books. It’s clearer this way. 16 | - Name variables created by a factory after the factory (`user_factory` creates user). 17 | - Name variables, methods, and classes to reveal intent. Intent describes the function of the class, method or variable. A typical example is if we were describing a class method to sort a collection by a certain parameter. It’s preferred to define this as `obj.sort_by(param)`. It makes code more readable and require less documentation. 18 | - Treat acronyms as words in names (`XmlHttpRequest` not `XMLHTTPRequest`), even if the acronym is the entire name (class Html not class HTML). 19 | - Suffix variables holding a factory with `_factory` (`user_factory`) 20 | 21 | **Formatting** 22 | - Avoid inline comments. 23 | - Avoid deep indentation. 24 | - Break long lines after 80 characters. 25 | - Delete trailing whitespace. 26 | - Don't include spaces after `(`, `[` or before `]`, `)`. 27 | - Don't misspell. 28 | - Don't vertically align tokens on consecutive lines. 29 | - Do not leave commented out code within production code. 30 | - If you break up an argument list, keep the arguments on their own lines and closing parenthesis on its own line. [Example 1](https://github.com/andela/code-review-guidelines/tree/master/style/ruby/sample.rb#L2), [Example 2](https://github.com/andela/code-review-guidelines/tree/master/style/ruby/sample.rb#L10). 31 | - If you break up a hash/dictionary/associative array, keep the elements on their own lines and closing curly brace on its own line. 32 | - Indent continued lines two spaces. 33 | - Indent private methods equal to public methods. 34 | - If you break up a chain of method invocations, keep each method invocation on its own line. Place the `.` at the end of each line, except the last. Example. 35 | - Use 2 space indentation (no tabs) or indentation specific to your stack. 36 | - Use an empty line between methods or the required number of spaces specified in the respective style guide. 37 | - Use empty lines around multi-line blocks. 38 | - Use spaces around operators, except for unary operators, such as `!`. 39 | - Use spaces after commas, after colons and semicolons, around `{` and before `}`. 40 | - Use [Unix-style line endings](http://unix.stackexchange.com/questions/23903/should-i-end-my-text-script-files-with-a-newline) (\n). 41 | - [Use uppercase for SQL keywords and lowercase for SQL identifiers](http://www.postgresql.org/docs/9.2/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS). 42 | 43 | **Code Organization** 44 | - Ensure to always take advantage of inbuilt language functionality like packages, modules etc. to organise the different parts of your code. 45 | - Order methods so that caller methods are earlier in the file than the methods they call. 46 | - Order methods so that methods are as close as possible to other methods they call. 47 | 48 | For language specific style guides, see below. 49 | 50 | _Note: It is helpful to run your code through a linter to easily help point you to areas where code is not conforming to style guides. Better still, plugins exist for various IDEs to help with this._ 51 | 52 | **Python** 53 | 54 | See [PEP-8 Style Guide](https://www.python.org/dev/peps/pep-0008/). 55 | 56 | **JavaScript** 57 | 58 | [Airbnb Javascript Style Guide](https://github.com/airbnb/javascript) is preferred. In addition to that, take note of the following general pointers. 59 | 60 | - Prefer ES6 classes over prototypes. 61 | - Use strict equality checks (`===` and `!==`) except when comparing against (null or undefined). 62 | - Prefer [arrow functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions) `=>`, over the function keyword except when defining classes or methods. 63 | - Use semicolons at the end of each statement. 64 | - Prefer single quotes. 65 | - Use `PascalCase` for classes, `lowerCamelCase` for variables and functions, `SCREAMING_SNAKE_CASE` for constants, `_singleLeadingUnderscore` for private variables and functions. 66 | - Prefer [template strings](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/template_strings) over string concatenation. 67 | - Prefer promises over callbacks. 68 | - Prefer array functions like `map` and `forEach` over for loops. 69 | - Use `const` for declaring variables that will never be re-assigned, and let otherwise. 70 | - Avoid `var` to declare variables, use `let` where applicable. 71 | 72 | **Ruby** 73 | 74 | We should ensure that there is strict adherence to [this style guide](https://docs.google.com/document/d/1V1YFusbUsG8rBd-XcS9gc31xI45s4DMQIrheMIeRqb8/edit#heading=h.oq7iz97r9dfi). 75 | 76 | **PHP** 77 | 78 | We should ensure that there is strict adherence to the [PSR-2 Coding Style Guide](http://www.php-fig.org/psr/psr-2/). 79 | 80 | **Java** 81 | 82 | We should ensure that all Java Code follows the [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html). 83 | -------------------------------------------------------------------------------- /getting-started/README.md: -------------------------------------------------------------------------------- 1 | # Before you start reviewing 2 | 3 | ### For Checkpoint Evaluation 4 | You can proceed to download the code onto your computer and open up with your favorite text editor. It is advisable to have the appropriate linter installed and configured on your IDE of choice. 5 | 6 | (TODO: Add in guides to download and configure linters on Sublime and computer) 7 | 8 | ### For Project Submissions 9 | Ensure that you have cloned the repository to your local environment. If you are reviewing a pull request, you can get the branch you would like to review by running `git checkout --track origin/`. You can then open up the code in your IDE of choice and start reviewing. Ensure you have a linter installed as mentioned earlier. 10 | 11 | ### Remember your SPECS 12 | The SPECS acronym summarise the philosophy we should embrace when doing code reviews. 13 | - Simplify Code 14 | - Practice Kindness 15 | - Explain Why & with Examples 16 | - Connect Learners 17 | - Style Consistently 18 | -------------------------------------------------------------------------------- /quality-checks/README.md: -------------------------------------------------------------------------------- 1 | # Now that you’ve started reviewing 2 | These are some of the things you should be looking out for when reviewing code. Majority of the item highlighted here can be applicable for both Checkpoint Reviews and Project Code Reviews. 3 | 4 | **Code Functionality** 5 | - Does the code work? Does it perform its intended function, the logic is correct etc. 6 | - Is the code robust? How does the code perform with extreme data? 7 | 8 | **Code Quality** 9 | - Is all the code easily understood? 10 | - Is there any redundant or duplicate code? 11 | - Is the code as modular as possible? 12 | - Can the code be refactored for clarity? 13 | - Can any of the code be replaced with library functions? (Note that this is not the case if the task at hand is purely algorithmic). 14 | - Does this code follow general and language specific best practices? 15 | - Does it conform to the agreed coding conventions? (See [Coding Style Guide](https://github.com/andela/code-review-guidelines/tree/master/coding-style-guides)) These will usually cover location of braces, variable and function names, line length, indentations, formatting, and comments. 16 | - Can any logging or debugging code be removed? Is there also any commented out code? 17 | 18 | **Code performance** 19 | - Can the code be refactored for performance? (See Performance) 20 | - Do loops have a set length and correct termination conditions? 21 | - Is there anywhere with sub-optimal performing code? 22 | - Can any global variables be replaced? 23 | - Can any logging or debugging code be removed? 24 | 25 | **Testing** 26 | - Is the code tested? (There is an exhaustive guide available here) 27 | - Might any piece of code introduce new bugs? 28 | -------------------------------------------------------------------------------- /style/ruby/sample.rb: -------------------------------------------------------------------------------- 1 | class SampleClass 2 | def method_with_long_signature( 3 | the_first_arg:, 4 | the_second_one:, 5 | and_another_one: 6 | ) 7 | # code here 8 | end 9 | 10 | def invoke_method_with_arguments_on_multiple_lines 11 | some_method( 12 | i_am_a_long_variable_name_that_will_never_fit_on_one_line_with_others, 13 | two, 14 | three 15 | ) 16 | 17 | # Bad: 18 | some_method(one, 19 | two) 20 | end 21 | end 22 | --------------------------------------------------------------------------------