How can you enforce coding standards and conventions with code review?

In my experience, maintaining consistent coding across projects is crucial for code quality, readability, and long-term maintainability. Also,encouraging developers to review their own code against the standards before submitting for review. This catches basic issues early and saves valuable review time. Timely Reviews and constructive, specific feedback focused on code improvement, not personal attacks fosters and gives room for improvement.

Coding standards help reduce cognitive load. When you know where to find specific pieces of code or understand how a particular pattern is used, you can focus more on the logic and problem-solving aspects of development rather than trying to decipher the code's structure. Also, consistent coding standards and conventions make our code more readable and maintainable. When you or your colleagues revisit the code in the future, it's much easier to understand, update, or extend when it adheres to a consistent structure. This is particularly valuable when dealing with legacy code or when onboarding new team members.

Coding standards and conventions can help to make software more secure by identifying and fixing common security vulnerabilities. Example: Checking code for security vulnerabilities before it's released helps to find and fix them early, before attackers can exploit them.

Consistency is key. Imagine diving into a codebase where every developer had their unique style - it would be chaos! Coding standards and conventions act as the playbook. They streamline code, making it predictable and easier to navigate. For new developers, this consistency feels like a roadmap, guiding them through the intricacies of a project. Furthermore, standards reduce the chances of bugs slipping in, as the code follows tried and tested patterns. It's not just about aesthetics; it's about writing code that's efficient, secure, and team-friendly. In essence, adhering to these standards is like speaking a common language in the developer community, ensuring clarity and cohesion.

Conventions, standards and adhering to a style guide are all important because they help people working on the project be more efficient. * Code readability - uniformity matters. When each file follows a consistent style, it easier for developers to understand the code's logic. * Easier to get started - It's much simpler to get into a new project when it follows familiar coding style. * Better collaboration - developers can help each other quicker and perform code reviews faster. * Reduce chance for human error - Sticking to standards can help developers avoid many basic mistakes and waste time on debugging them later.

To add to what people have mentioned already, make sure that your tools have: * Integration with GIT or your other version control system * Easy to read inline comments and general comments for the entire PR/MR * A set of automated checks * Ability to create (and later resolve) issues Two widely available tools that I can personally suggest are GitHub and GitLab. They both have lot's of helpful features, integrations and comfortable user interfaces.

Tools like GitHub or SonarQube, are more than just platforms; they're ecosystems equipped with features that enhance the review process. Syntax highlighting, for instance, makes code more readable, while code diffing shows changes made, ensuring nothing slips through. For a React developer, tools that offer code suggestions or analyze code quality can be invaluable, pinpointing potential pitfalls or inefficiencies. By leveraging these tools, not only do you streamline the review process, but you also foster a culture of continuous learning and improvement within your team.

It is best to use code review tools at a more 'strict' level to start off with. At a later stage, coding standards tend to improve with practice and then we can normalize the rules used in the tool.

The version control platform you use is the backbone of your code reviewing process. All famous platforms have a fairly advanced ecosystem for you to use. Make yourself familiar with its functionalities. If you're new to it, ask a colleague. Sharing the most used functionalities takes no more than 15 minutes and it will give you both a valuable fresh perspective.

At times code reviews may lead to leniency on the part of the developer assuming that he/she can get away with flaws which may later be caught during review. To prevent such scenarios, both developer & reviewer should be made responsible for the review and its outcome. It is slippery ground and one needs to approach with caution.

Some of the best practices we follow: 1. PR template 2. Code review checklist items added to PR in an automated way by PR template 3. Completion criteria for code review - Make it a requirement that all checklist items must be marked as "completed" and approved by reviewers before merging the PR.

As someone who submits a PR: * Separate PR to only touch a single topic at a time. Do not mix numerous changes in the same PR. * Try to keep the changes small and aim for incremental updates rather than massive overhauls. * Clarify the PR's goal - the reviewer should easily understand the purpose of the code and the problem it solves. * Add tests if necessary. * Ensure that all tests pass before submitting a PR. * Ensure that you have updated the comments / documentation. * Ensure that you follow the guidelines and standards. As someone who reviews the PR: * Be constructive * Be polite * Maintain objectivity * Stay flexible

It's important to create an environment where comments on pull requests are not viewed as "bashing" on someone's code. They're suggestions to make it better. They're flags of vulnerabilities. They are opportunities to improve. One of the best environments I've had as a software engineer was in a team where we posted a lot of comments. We had become so used to comments on our PRs that we understood that it's something that every person gets no matter what seniority they are. Having a healthy reaction to comments is imperative to growing as a software engineer.

Quality gates in CI give confidence and a headstart for code reviewers to focus on the review of the core business logic. Below are a few things, that we have automated by adding robust quality gates in CICD pipelines. 1. Linter checks for coding style and standards 2. Security Scanning 3. Unit test coverage (% code coverage is improved or degraded by PR) 4. Integration tests On top of this utilizing Generative AI-LLM-based code review assistant(Github Actions workflow) can also help to provide good feedback for the pull request and semi-automate the code review process. Apart from these, there are some kind of pull requests for example dependency updates can be made Auto Merge enabled if all the quality gates in CI are passing.

I've seen how easy it is to miss minor inconsistencies or potential vulnerabilities. Enter automated code review tools. Linters, for instance, can automatically flag style or syntax inconsistencies, ensuring that your React components are not only functional but also clean. Meanwhile, hooks can be set up to trigger these tools before any code is merged, ensuring that any potential issues are caught early. This isn't about replacing the human touch in code reviews but enhancing it. It's about giving developers the tools to catch the low-hanging fruit, allowing them to focus on more complex, logic-based concerns. Automating parts of the review process means more reliable code and, ultimately, a smoother user experience.

* Use static code analysis tools like linters (e.g. PyLint). * Use code formatters (e.g. Python Black, Go fmt) * Optionally use pre-commit hooks (but it's better to enforce that on the CI side). * CI - set up a sophisticated CI pipeline that runs all of the linters, formatters, tests and other necessary operations. This is great, as even if the developer forgets to run all of the tools on their side - the final version of the code will be scanned (and potentially modified) with those tools.

While what others have shared here about tools like ESLint and SonarQube is true, I would also like to mention that you should not aim to automate the entire review process. There should always be at least one colleague taking a look at your code. While automated tools are great, they can miss business process specifics that only developers working on the product can see.

In my experience, you can't fully automate code review. Code style checks and linters are good, but they can't encompass the bigger picture or clean code issues. For these you'll need check-lists and guidelines documented somewhere for everyone to see.

* There should be an open channel for a feedback loop between the participants. * Treat code reviews as a learning process. * Knowledge sharing sessions

If feasible, code reviews should be done in pairs (developer+reviewer). It helps in strengthening reviews, coding standards and improving quality of code.

Never take review comments personally. They are neither an attack on your code nor an attack on you as a developer. You should also never do those things to your peers. Review the code, not the person behind it. Ego should stay out of code reviews. Make it a discussion if needed. I've sometimes needed to contact the reviewer for a short call or to go to his workstation so we can discuss the review face to face. It's nothing to feel uncomfortable about and it can open your eyes to problems you couldn't see before.

Code reviews serve as a learning tool by providing feedback on coding practices. Developers can learn from peers through the review process, gaining insights into best practices and improving their future code. Teams can also track common issues and address them through training or documentation.

I think having 2 or more people to review your code is a good idea. There are also many editor and CI/CD plugins which can help enforce coding standards and conventions.

* Establish a positive code review culture where the goal is to improve the project and empower developers, not to criticize. * Teach the teammates how to properly submit a PR and how to properly review one. * Optionally, have a review checklist. * Encourage pair programming - this will reduce time spent on code reviews and improve all participants on the way. * Tools are good, but remember that they won't always catch everything. * When reviewing changes, look at each line. Stay concentrated and don't just trust the changes. Even the best engineers make mistakes, forget stuff and miss on the most basic things sometimes.

Coding standards followed in the team should be guidelines that all developers believe in and follow. The success of such practices lie more in the people applying it than on the process itself. A simple yet thorough review process helps to elevate the quality of code in the team.

Beyond the immediate code review, enforce coding standards by documenting guidelines, conducting regular knowledge-sharing sessions, and making code quality a key performance indicator. Ensure that the review process itself is also reviewed and updated regularly to adapt to new standards or changes in technology. A culture that values code quality and continuous improvement will naturally enforce better standards and conventions.