Code cleanup

This article has been nominated for deletion since 16 November 2024. To discuss it, please visit the talk page. Do not remove this tag until the discussion is closed. Reason for the nomination: This article either contains out of date information, and/or may not meet the quality standards of the wiki, potentially to the point of causing confusion or frustration to readers.

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.