24 October 2022 by Phillip Johnston • Last updated 26 February 2024A core axiom of our software engineering philosophy is that we want to minimize time to defect discovery. We have observed that the longer an error remains in a program, the harder it is to fix. The best time to fix an error is immediately after you introduced it. You have the full context loaded into your mind. You understand what you’re trying to do, why you just wrote the code the way you wrote it, and what the target behavior is. The defect is often obvious – and …
Continue reading “Minimize Time to Defect Discovery”
24 October 2022 by Phillip Johnston • Last updated 16 October 2024Memory is usually viewed as a limited resource in embedded systems. As a result, monitoring memory usage is a common analysis and quality enforcement activity. This is often done for both resource management reasons and preventing critical errors, such as stack overflows, heap exhaustion, and heap fragmentation. Stack Usage A linker can usually check whether or not your global variables will fit into the available RAM, but it cannot tell how much stack you need. This means that there is guesswork involved in sizing stacks. With limited memory, we …
Continue reading “Monitoring Memory Usage”
10 May 2022 by Phillip JohnstonIt is popular at the moment to rail against code reviews as waste, especially when teams adopt beneficial practices such as pair programming, static analysis, testing and automated standards enforcement. After all, if we have invested time to put these practices and processes in place, why do you need to “waste time” reviewing code when developers could instead be writing more of it? Certainly, there are other processes and practices you will adopt that will aid you in finding defects and improving the quality of your code even before it hits the review stage. But …
Continue reading “Automated Quality Enforcement Does Not Eliminate The Need for Peer Code Review”
10 May 2022 by Phillip JohnstonStandards are an essential component of code reviews: they let teams know in advance what is expected of the code that they write. However, having your reviewers enforce standards compliance moves their focus away from finding defects, which is the core code review value proposition. Luckily, you can automate the enforcement of many (but not all) standards selected by your team. Auto-formatting tools, such as clang-format, can be used to auto-format all of your source code to ensure it complies with the team’s style requirements. Adherence to the style guides can be checked by your …
Continue reading “Automate Standards Enforcement to Improve Code Reviews”
9 May 2022 by Phillip JohnstonA common difficulty with code reviews is that they often degrade into debates about style. There is a simple solution to this: do not allow debates on style in a code review. Likewise, do not allow debates on whether or not the style guide is correct. Instead, focus the team on identifying defects and deviations from agreed upon coding standards. The best approach to eliminating debates about style is to automate the formatting process. There are a number of code formatting tools that can be used to specify and enforce a specific coding standard. Have …
Continue reading “Code Reviews are not About Style”
9 May 2022 by Phillip JohnstonWhen reviewing code, search for TODO or FIXME style comments in the changes. These comments indicate unfinished work, and they should not be merged in. Some developers may indicate that the comments are not related to their current changes, but instead: Were previously deferred work, not something they added with the change set Aren’t required in the current changes, but serve as reminders or placeholders for upcoming work If the upcoming or deferred work is important enough, it should be tracked as an issue or task within the team’s system of choice so that it …
Continue reading “Look for TODOs and FIXMEs Comments During Reviews”
