Difference between revisions of "Development: Code Review"

From LinuxTVWiki
Jump to: navigation, search
(Why)
(some edits, fixed links)
Line 1: Line 1:
== Definition ==
+
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.
  
A Code Reviewer is somebody who looks on the source code, checks it for correctness and thinks about optimizations.
+
== Why have a Code Review? ==
  
== Why ==
+
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 its presence is finally realized (i.e end user reports an error that is ultimately traced to being derived from the bug in the code that was present all along). The only way to make the linux-dvb code as stable and robust as possible is by having as many developers as possible analyze the source and watch out for potential bugs and weaknesses.
  
Nobody is perfect, we are human too. Even today then and when a bug shows up we did not recognized before. The only way to make the linux-dvb code as stable and robust as possible is that as many developers as possible analyze the source and watch out for potential bugs and weaknesses.
+
== When should you have a code review? ==
 
+
== When ==
+
  
 
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.
 
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.
  
When you get a nice idea how to make things better or to introduce [[Performance Optimisation]]s then please start a thread on the linux-dvb Mailing List and let's discuss it.
+
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 into the [[Hints for Refactoring existing DVB drivers]] section in this Wiki.
+
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]]

Revision as of 19:36, 7 January 2008

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.

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 its presence is finally realized (i.e end user reports an error that is ultimately traced to being derived from the bug in the code that was present all along). The only way to make the linux-dvb code as stable and robust as possible is by having as many developers as possible analyze the source and watch out for potential bugs and weaknesses.

When should you have a code review?

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.

When you get a nice idea how to make things better or to introduce 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 "Hints for Refactoring existing DVB drivers" article.