Lines Matching refs:code
4 This document provides TF-A specific details about the project's code review
9 Why do we do code reviews?
12 The main goal of code reviews is to improve the code quality. By reviewing each
13 other's code, we can help catch issues that were missed by the author
19 community. People with more expertise in one area of the code base can
29 To ensure the code review gives the greatest possible benefit, participants in
39 code review helps everyone in the long run, as it creates a culture of
56 In the event that a code review takes longer than you would hope for, you
62 - If one code owner has become unresponsive, ask the other code owners for
65 - If there is only one code owner and they have become unresponsive, ask one
68 - Do the right thing for the project, not the fastest thing to get code merged.
70 For example, if some existing piece of code - say a driver - does not quite
71 meet your exact needs, go the extra mile and extend the code with the missing
72 functionality you require - as opposed to copying the code into some other
90 Guidelines for code owners
93 Code owners are listed on the :ref:`Project Maintenance<code owners>` page,
96 When reviewing a patch, code owners are expected to check the following:
100 - The structure of the code is clear.
116 - (Only applicable to generic code) The code is MISRA-compliant (see
127 If a code owner is happy with a patch, they should give their approval
145 - Be mindful when reviewing a patch. As a code owner, you are viewed as
164 For example, platform code should be added under the ``plat/`` directory.
169 name clashes with generic code.
173 - Interaction of the patch with other modules in the code base.
182 - There is no third party code or binary blobs with potential IP concerns.
183 Maintainers should look for copyright or license notices in code, and use
187 - Generally speaking, new driver code should be placed in the generic
193 type of code duplication hurts the maintainability of the project. The