Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Difference between revisions of "Code cleanup"

From FlightGear wiki
Jump to: navigation, search
 
m (Carelessness)
 
(18 intermediate revisions by 10 users not shown)
Line 1: Line 1:
The purpose of this page is to provide a todo-list or check-list for anyone that wants to help clean up the Flightgear (FG) code. In addition to this list, you also want to try running FG in Valgrind, a very powerful memory debugger and profiler. http://freshmeat.net/projects/valgrind/  
+
{{Out of date}}
 +
The purpose of this page is to provide a todo-list or check-list for anyone that wants to help '''clean up the [[Flightgear]] code'''. In addition to this list, you also want to try running FlightGear in [http://freshmeat.net/projects/valgrind/ Valgrind], a very powerful memory debugger and profiler.
  
'''Feel free to add additional items to this page'''
+
A list of articles related to code cleanup can be found in [[:Category:Code Cleanup]].
  
Thanks -- Cameron Moore
+
''Feel free to add additional items to this page!''
  
== Major Task List ==
+
== Keyboard reorganisation ==
 +
The input settings (especially the keyboard) need some TLC. Here are the major tasks (we need to work on the first one first):
  
 +
* [[Keyboard function priority list]] — come up with a priority list of functions that need global keyboard assignments for ''all'' aircraft, without worrying about the specific keys.
 +
* Local key block — decide on a block of keys to set aside for per-aircraft assignment.
 +
* Global key bindings — decide what keys to assign to the functions from the opening list (not using the local key block).
 +
* Refactor models — refactor all of the aircraft models so that they assign keys only from the local, per-aircraft key block.
 +
* Add a GUI — add a GUI allowing users to reassign keys while the sim is running and save their changes.
 +
 +
== Major Task List ==
 
* Move code out of fgMainLoop() and into separate functions or source files.
 
* Move code out of fgMainLoop() and into separate functions or source files.
 
* Replace system() calls in simgear/io/sg_binobj.cxx to `mkdir`
 
* Replace system() calls in simgear/io/sg_binobj.cxx to `mkdir`
 
* Replace system() call in simgear/io/sg_binobj.cxx to `gzip`
 
* Replace system() call in simgear/io/sg_binobj.cxx to `gzip`
 
* Allow aircraft to be reliably changed at runtime, without requiring a restart of FlightGear
 
* Allow aircraft to be reliably changed at runtime, without requiring a restart of FlightGear
* Replace all hardcoded PLIB PUI dialogs with dynamic XML dialogs that use FGDialog, this will require some additional Nasal hooks, so that more complex dialogs (e.g. the property browser or airport list) can actually be realized using XML & Nasal alone.
 
 
* Implement scenery support for dynamic LOD configuration at runtime
 
* Implement scenery support for dynamic LOD configuration at runtime
 
* Optimize the 3D panel code and optionally support display list usage
 
* Optimize the 3D panel code and optionally support display list usage
* Make Textures reloadable at runtime for debugging and development purposes
 
 
* Add OpenGL bindings to the scripting language Nasal to support scripted creation of instruments like the HUD
 
* Add OpenGL bindings to the scripting language Nasal to support scripted creation of instruments like the HUD
* Helicopter flight is still not yet modelled too convincingly, it would be good if someone could either take the time and add realism to the current FDMs or maybe ven come up with a new dedicated helicopter FDM altogether?
+
* Encourage liberal use of SGSharedPointer whereever raw pointers are currently used
 +
* Split up unnecessarily large files into several separate compilation units, which should eventually also speed up compilation
  
 
== Persistent Checklist ==
 
== Persistent Checklist ==
 
 
=== Carelessness ===
 
=== Carelessness ===
* Properly allocate and deallocate memory using malloc/new/new[{][}] and free/delete/delete[{][}].
+
* Properly allocate and deallocate memory using malloc/new/new[] and free/delete/delete[]. Valgrind is helpful when looking for these.
 
+
* Close any open file streams when you're through with them. Take care to not write to or close streams that aren't open. Avoid this by initializing file pointers/handles with 0 before use and verify that it is not 0 before accessing/closing.
Valgrind is helpful when looking for these.
+
  
 
=== Compatibility ===
 
=== Compatibility ===
 
 
* Use the SG_LOG() facilities instead of cout and printf().
 
* Use the SG_LOG() facilities instead of cout and printf().
 
* Use the SG_USING_STD() facilities instead of explicitly using std::function.
 
* Use the SG_USING_STD() facilities instead of explicitly using std::function.
 
* Use the STL_* variables defined in simgear/compiler.h when including STL headers.
 
* Use the STL_* variables defined in simgear/compiler.h when including STL headers.
 
* When including header files, only use double-quotes when the header is in the same directory.
 
* When including header files, only use double-quotes when the header is in the same directory.
 
=== Performance ===
 
 
* When performance is crucial, consider using the "fastmath.hxx" headers.
 
  
 
=== Security ===
 
=== Security ===
 
 
* Use C-string functions with fixed write buffers whenever possible to avoid buffer overflows.
 
* Use C-string functions with fixed write buffers whenever possible to avoid buffer overflows.
 +
* Perform range/bounds checks on all data received from remote that could cause problems, especially those that specify an amount of data to be handled.
  
 
For example, use snprintf() instead of sprintf() and strncpy() instead of strcpy().
 
For example, use snprintf() instead of sprintf() and strncpy() instead of strcpy().
 +
 +
And please do not forget that snprintf and strncpy does not necessarily add a trailing 0 byte.
 +
 +
[[Category:Code Cleanup| ]]
 +
[[Category:Development]]

Latest revision as of 20:08, 28 June 2013

This article or section contains out-of-date information

Please help improve this article by updating it. There may be additional information on the talk page.

The purpose of this page is to provide a todo-list or check-list for anyone that wants to help clean up the Flightgear code. In addition to this list, you also want to try running FlightGear in Valgrind, a very powerful memory debugger and profiler.

A list of articles related to code cleanup can be found in Category:Code Cleanup.

Feel free to add additional items to this page!

Keyboard reorganisation

The input settings (especially the keyboard) need some TLC. Here are the major tasks (we need to work on the first one first):

  • Keyboard function priority list — come up with a priority list of functions that need global keyboard assignments for all aircraft, without worrying about the specific keys.
  • Local key block — decide on a block of keys to set aside for per-aircraft assignment.
  • Global key bindings — decide what keys to assign to the functions from the opening list (not using the local key block).
  • Refactor models — refactor all of the aircraft models so that they assign keys only from the local, per-aircraft key block.
  • Add a GUI — add a GUI allowing users to reassign keys while the sim is running and save their changes.

Major Task List

  • Move code out of fgMainLoop() and into separate functions or source files.
  • Replace system() calls in simgear/io/sg_binobj.cxx to `mkdir`
  • Replace system() call in simgear/io/sg_binobj.cxx to `gzip`
  • Allow aircraft to be reliably changed at runtime, without requiring a restart of FlightGear
  • Implement scenery support for dynamic LOD configuration at runtime
  • Optimize the 3D panel code and optionally support display list usage
  • Add OpenGL bindings to the scripting language Nasal to support scripted creation of instruments like the HUD
  • Encourage liberal use of SGSharedPointer whereever raw pointers are currently used
  • Split up unnecessarily large files into several separate compilation units, which should eventually also speed up compilation

Persistent Checklist

Carelessness

  • Properly allocate and deallocate memory using malloc/new/new[] and free/delete/delete[]. Valgrind is helpful when looking for these.
  • Close any open file streams when you're through with them. Take care to not write to or close streams that aren't open. Avoid this by initializing file pointers/handles with 0 before use and verify that it is not 0 before accessing/closing.

Compatibility

  • Use the SG_LOG() facilities instead of cout and printf().
  • Use the SG_USING_STD() facilities instead of explicitly using std::function.
  • Use the STL_* variables defined in simgear/compiler.h when including STL headers.
  • When including header files, only use double-quotes when the header is in the same directory.

Security

  • Use C-string functions with fixed write buffers whenever possible to avoid buffer overflows.
  • Perform range/bounds checks on all data received from remote that could cause problems, especially those that specify an amount of data to be handled.

For example, use snprintf() instead of sprintf() and strncpy() instead of strcpy().

And please do not forget that snprintf and strncpy does not necessarily add a trailing 0 byte.