今日推荐开源项目：《中文代码补全 vscode_Chinese_Input_Assistant》
今日推荐英文原文：《10 Things to Look for in Every Code Review》
今日推荐开源项目：《中文代码补全 vscode_Chinese_Input_Assistant》传送门：GitHub链接
推荐理由：如果说文言编程只是为了好玩的话，那么这个插件相对而言有着更多的实用性（或许吧）。这款 VS Code 插件能用中文表达部分语法，添加中文变量，更重要的是提供包含全拼、双拼、五笔等方式的代码快速补全。
今日推荐英文原文：《10 Things to Look for in Every Code Review》作者：Julie Elise
原文链接：https://medium.com/better-programming/10-things-to-look-for-in-every-code-review-3f7fe67ba817
推荐理由：毕竟重新检查一遍代码是个复杂且枯燥的工作。
10 Things to Look for in Every Code Review
A guide to making your code more maintainable and robust
Code reviews are an integral part of the development process. They help to ensure you’re building robust and maintainable tools. The benefits of code reviews include increasing visibility of a project, sharing knowledge among team members, and, most importantly, detecting bugs and improving maintainability.Any developer putting their code up for review wants constructive feedback. Feedback should not be limited to notes about style, line spacing, or naming.
The main focus of a code review should be on giving constructive feedback that will make the code more readable, maintainable and bug free.
Here are the top 10 things to look out for in every code review.
1. Functionality
Does the code do what the developer intended? First and foremost, the code reviewer is responsible for checking if the goals defined in the code review are met. Have the changes addressed all features or bug fixes?2. Design
In an ideal world, any software design changes would have been discussed and evaluated before implementation. Alas, we don’t live in a perfect world, so there may be occasions where the design was not discussed beforehand and an extensive refactoring is needed to bring the code changes up to standard.- Check to see if the proposed design pattern matches the changes in the code review. How is the program logic divided among classes and how do these classes interact with each other?
- Does the code adhere to object-oriented design principles?
- Is the UI code separate from the logic code? Are components divided up in a way that makes sense?
- Are the files in the project organized intuitively? For instance, are UI files, images, scripts, classes, and headers all in separate folders?
3. Identify Repeated Code
Don’t Repeat Yourself (DRY)Repeated code is a recipe for repeated bugs, increased complexity, and unnecessary overhead. Don’t Repeat Yourself (DRY) is a common mantra among software developers.
Reasons to avoid repeated code:
+ It makes the codebase lengthy and harder to maintain. + A maintainer could potentially fix a bug in one place but not the other. + Repeated code means that a repeated number of tests will need to be run. How to Fix:
+ If functionality is repeated throughout a class this code should be moved to a single function. + If this repeated code is used across multiple projects the code should be added to a submodule or separate project, which is referenced by all projects. + Is there repeated functionality in multiple classes? Ensuring that inheritance is used will reduce the number of repeated functions.
4. Consider Run Time of Algorithms
The run time of an algorithm depends on the number of operations executed and can be expressed in Big O notation. The more operations, the more time it takes to run the application.+ Are there any unneeded operations? All unnecessary calculations should be removed. + Is the algorithm doing repeated work? Can we cache the data using memoization to avoid running the same computation more than once? + Identify nested loops. Is there a way to simplify the operations without using them? + What is the lookup cost when accessing data? Is there a data structure that could be used to reduce it?
5. Remove All Hardcoded Values in the Code
Hardcoded values are a firm “no.” If hard-coded values need to exist in the project use constants and descriptive variable names.+ Constants specific to a class should be added as static class variables. + Configurable constants should be part of a configuration class. + Constants that aren’t configurable and that are shared between classes should be in a constant file and only included as needed.
6. Error Handling
Does the code contain thorough error handling?+ Exceptions should handle invalid inputs due to user input, hardware constraints, network issues, etc. + Assertions should validate conditions to help detect bugs and validate test cases.
7. Memory Allocation
Memory allocation can be error-prone if malloc() or free() is misused. A detailed list of the top dangerous software errors due to memory allocation can be found here.+ Memory leaks will occur if unused objects in memory are never freed. This will cause the application to use more memory than it needs and potentially slow down the system. + Premature freeing occurs when an object that’s still used by the program is freed. The result is a stale pointer, which will cause further calls to malloc and free to crash. + An object can be double freed by freeing an object that’s already free. Again, future calls to malloc and free may crash. You’re less likely to run into memory allocation issues when working with languages such as Python that have built-in garbage collection.
8. Comments
If it’s unclear why a portion of code exists, that’s a good indication that a comment is needed.+ Comments should be concise and actionable. + Comments should explain why the code exists — not what the code is doing. + IDE comment keywords such as
TODO, FIXME, CHECKME, PENDING, etc should be used to identify specific categories of comments.
9. Consistency
The style throughout the codebase should be consistent in terms of the naming, spacing, and brackets. Ideally, the style guidelines have already been established by your team.+ Is the function, variable, and class naming consistent? + If there isn’t a style guide, the code should maintain consistency with the rest of the codebase.
10. Safe Parallel Programming
If the code contains parallel programming, it’s essential to check for deadlocks and race conditions. These issues can be challenging to test by just running the code, so it’s critical to have this looked at by another developer.Additional Resources
Here are some standard code review tools:+ Crucible + Review Board + Gitlab
(Gitlab Code Review From Gitlab Release Notes)Coding style guidelines:
+ Python Pep 8 Style Guide + Google C++ Style Guide + Google Javascript Style Guide
Conclusion
I hope this article has given you more insight into what to look for when reviewing code.If you follow the guidelines in this article, code reviews can reduce bugs, and ensure consistency, efficiency, and maintainability.
If you don’t currently require code reviews on your team, I hope this article has convinced you of the important part they play in developing and maintaining robust systems.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
