Code Review Triage

From Audacity Wiki
Revision as of 22:49, 11 February 2010 by James (talk | contribs) (Review by Martyn.)
Jump to: navigation, search
This page is associated with the code review initiative. The intention is to classify different issues found in code review, with discussion on the talk page.



We're currently using this triage list for general points that are not specific to one piece of code or algorithm.


Urgent

  • There is a lot of use of 'new/delete' in working with sample buffers and envelope point buffers. These are typically allocated and deallocated with every repaint of the screen. This is inefficient, causes memory fragmentation and is 'unchecked'. The success/failure of the new/delete is unchecked (minor). The indexing into the buffers is unchecked (major). We need a "SmartBuffer" that can as an option allocate on-stack to rectify this. It could also alert us if very large buffer sizes were requested e.g. with zoomed out views of large projects.
  • Some files have missing or incomplete header comments. As a result the classes they contain are not being described in Doxygen listings, or indeed in the code.


May Do Now

  • The vim indent setting footers at the end of every page are (arguably) just an annoyance. Needs checking on audacity-devel that there is a consensus that they are not such a good idea after all.
  • Lots of repetitive code where idioms like value=constrain(value,min,max); can make the code shorter and clearer. In many cases small helper functions would be good.
  • There are lots of cases of long functions where splitting the functions up into component functions each with a well chosen name would be helpful - or at the very least we should add a comment.
  • Cut-and-paste code in related classes, not sufficiently exploiting the commonality in classes by using functions in the base class.


Do Later

  • Tag handling is verbose code, rather like how dialog building code was before ShuttleGui. A similar technique could make this code much more readable.


Links to some reviews

Pending Reviews

  • Timetracks/Play-at-speed (started)
  • Multi-Clip
  • ASSERTs. Some should be generating end-user warnings
  • Load on-demand
  • Label Linking
  • ProgressDialog code
  • Checking of new/delete malloc/free failure conditions
  • Review of TagHandling. There is more processing happening in these functions than at first meets the eye and some is very relevant to stability. I (James) am tending to skip these in quick per-file code reviews because of their verbosity.