Development: Code Review

From LinuxTVWiki

(Difference between revisions)
Jump to: navigation, search
m (Why have a Code Review?: minor)
m (add link)
 
(7 intermediate revisions not shown)
Line 1: Line 1:
-
We define a "Code Reviewer" as somebody who carefully looks over submitted source code, checking it for correctness, thinks about areas for potential optimization, and then reports or provides such feedback to the original authour.
+
We define a "code reviewer" as somebody who carefully looks over [[Development: How to submit patches|submitted source code]], checking it for correctness and considers areas in which it could potentially be optimized, and then reports or provides such feedback to the original authour.
== Why have a Code Review? ==
== Why have a Code Review? ==
 +
Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. This is particularly true in software development, as it is often the case that an unrecognized bug makes its way into production code.  Therein, the bug will remain latent until it manifests itself in some more obvious way and then, only after which time, its presence is finally realized (i.e an end user encounters and [[Bug Report|reports an error]] which is ultimately traced to being derived from a bug that has been present in the source code all along).
-
Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into the code, and then remains latent until it manifests itself in some more obvious way and, only after which, its presence is finally realized (i.e end user reports an error that is ultimately traced as being derived from a bug in the code that has been present all along). The only way to make the linux-dvb code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.
+
== When should you have a Code Review? ==
 +
Consequent to the above question as to why have a code review, having a code review is an integral part of the process for new [[Development: How to submit patches|driver and patch submissions]] to the V4L-DVB code base. The only way to make the [[What is V4L or DVB?|V4L-DVB]] code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.
-
== When should you have a code review? ==
+
==Similar Concepts to a Code Review==
 +
When you get a good idea on how to improve the existing code base, such as by introducing [[Development: Driver Performance Optimisations|performance optimisations]], or wish to introduce something entirely new to its feature set, please start a RFC (review for consideration) thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media Linux-Media Mailing List] (like this, [http://www.mail-archive.com/linux-media@vger.kernel.org/msg09831.html for example]) and let's discuss this/these idea(s). 
-
If you encounter a bug please file a [[Bug Report]] to the linux-dvb Mailing List or even better, send a [[Bugfix]] in unified diff format created with ''cvs -q diff -pu > patchname.diff'' to the mailing list.
+
Also note that when you encounter a point where you see that it would make much more sense to completely rewrite portions of the V4L-DVB source code, you are now dealing with the much deeper process of '''refactoring'''; please have a look at the "[[Development: Hints for Refactoring Existing Drivers|Hints for Refactoring Existing drivers]]" article for more information.
-
 
+
-
When you get a nice idea how to make things better or to introduce [[Development: DVB Driver Performance Optimisations|performance optimisations]] then please start a thread on the linux-dvb Mailing List and let's discuss it.
+
-
 
+
-
As soon you encounter a point where you see that it would make sense to rewrite portions of the code, to get into a deeper refactoring process, please have a look at the "[[Development: Hints for Refactoring existing DVB drivers|Hints for Refactoring existing DVB drivers]]" article.
+
[[Category:Development]]
[[Category:Development]]

Latest revision as of 03:08, 19 September 2009

We define a "code reviewer" as somebody who carefully looks over submitted source code, checking it for correctness and considers areas in which it could potentially be optimized, and then reports or provides such feedback to the original authour.

Why have a Code Review?

Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. This is particularly true in software development, as it is often the case that an unrecognized bug makes its way into production code. Therein, the bug will remain latent until it manifests itself in some more obvious way and then, only after which time, its presence is finally realized (i.e an end user encounters and reports an error which is ultimately traced to being derived from a bug that has been present in the source code all along).

When should you have a Code Review?

Consequent to the above question as to why have a code review, having a code review is an integral part of the process for new driver and patch submissions to the V4L-DVB code base. The only way to make the V4L-DVB code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.

Similar Concepts to a Code Review

When you get a good idea on how to improve the existing code base, such as by introducing performance optimisations, or wish to introduce something entirely new to its feature set, please start a RFC (review for consideration) thread on the Linux-Media Mailing List (like this, for example) and let's discuss this/these idea(s).

Also note that when you encounter a point where you see that it would make much more sense to completely rewrite portions of the V4L-DVB source code, you are now dealing with the much deeper process of refactoring; please have a look at the "Hints for Refactoring Existing drivers" article for more information.

Personal tools