Difference between revisions of "Development: Code Review"

From LinuxTVWiki
Jump to: navigation, search
m (minor changes)
m (fixed link)
Line 9: Line 9:
 
When you get a good idea on how to make something better or wish to introduce [[Development: DVB Driver Performance Optimisations|performance optimisations]], please start a thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media linux-media mailing list] and let's discuss this/these idea(s).   
 
When you get a good idea on how to make something better or wish to introduce [[Development: DVB Driver Performance Optimisations|performance optimisations]], please start a thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media linux-media mailing list] and let's discuss this/these idea(s).   
  
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.
+
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 Drivers|Hints for Refactoring Existing drivers]]" article.
  
  
 
[[Category:Development]]
 
[[Category:Development]]

Revision as of 00:48, 18 January 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. 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 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?

If you encounter a bug please file a Bug Report or, even better, send in a Bugfix !

When you get a good idea on how to make something better or wish to introduce performance optimisations, please start a thread on the linux-media mailing list and let's discuss this/these idea(s).

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 "Hints for Refactoring Existing drivers" article.