Development: Hints for Refactoring Existing Drivers: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
== What is ''Refactoring''? == |
|||
Keep it simple. |
|||
| ⚫ | |||
---- |
|||
''Links:'' |
|||
| ⚫ | |||
== Keep it Simple == |
|||
The simpler the resulting code is the easier it will be to maintain. Even from the performance point of view simple code is often preferable. |
|||
If you want to see some impressive code following this approach you may want to check out one of Fabrice Bellards Projects, e.g. [http://fabrice.bellard.free.fr/TinyGL/ TinyGL] or the ID software GPL games [http://www.idsoftware.com/business/techdownloads/ Doom, Quake & Co]] Great to learn performant and compact Coding. |
|||
So please: '''Whatever you do, keep it simple.''' |
|||
== Please do never ever apply big Changes in-place == |
|||
If you plan to rewrite bigger portions of the code please don't create a huge patch or thousands of patches but fork the relevant code modules so that people can easily test them concurrently with the old code and are free to use the old, usually well-tested code until your new version has matured. |
|||
There have been several situations in the past where the linux-dvb CVS was barely usable for weeks or months because we did not followed this principle. Please respect that other people are using the linux-dvb source in productive environments. |
|||
Revision as of 20:03, 24 September 2004
What is Refactoring?
A short definition of the Refactoring Process on Wikipedia, mentioning the important facts
Keep it Simple
The simpler the resulting code is the easier it will be to maintain. Even from the performance point of view simple code is often preferable.
If you want to see some impressive code following this approach you may want to check out one of Fabrice Bellards Projects, e.g. TinyGL or the ID software GPL games Doom, Quake & Co] Great to learn performant and compact Coding.
So please: Whatever you do, keep it simple.
Please do never ever apply big Changes in-place
If you plan to rewrite bigger portions of the code please don't create a huge patch or thousands of patches but fork the relevant code modules so that people can easily test them concurrently with the old code and are free to use the old, usually well-tested code until your new version has matured.
There have been several situations in the past where the linux-dvb CVS was barely usable for weeks or months because we did not followed this principle. Please respect that other people are using the linux-dvb source in productive environments.