This page contains the current list of the tasks that need to be done as part of the Framework Re-Factor. The goal is the allow volunteers to select a task and provide a patch that will resolve each of the tasks listed. The list of tasks have three degrees of difficulty complexity (Difficult, Moderate and Easy) allowing contributors at any level to participate.

To pick up any of these tasks

1. Add your name to the "Who is working on it" column
2. Create a JIRA Issue for the task (e.g use the name or area as the title and copy the what needs to be done into the issue description)
3. Remember to use the trunk as the code source for your re-factor and patch

In order to improve the quality of what is being refactoredre-factored, please note that for each task the developer should also:

• Create a JIRA issue (NOTE: this may be a sub-task)
• Write unit tests for every line of code being refactoredre-factored.

    <condition>
        <if-has-permission permission="ACCOUNTING" action="_ADMIN"/>
    </condition>

Still want to help but in other areas ?

If our current re-factor to do list seem a little too much for you to take on then you can help in other areas too, and a little bit of work quickly adds up.  Please take a look below for some other ideas for helping remove clutter and help clean up the code base.

• Obsolete / irrelevant comments: anything out of date
• Commented out code:  it belongs in the version control system
• Functions with too many arguments: anything beyond 3 arguments is probably too much unless there is a good reason for it.
• Functions that do too many things - multiple languages in the same text file
• Big files / Big classes / Big anything really!
• Duplication and cut-and-paste patterns
• Mixed levels of abstraction: You can't declare high level stuff like starting the framework with details like flag parsing in the same place. Things should read like a story from high level down to the details. Main calls higher level functions which then call lower functions which executes detailed code.
• Any concrete class not implementing an interface is probably a code smell, especially if too many dependencies point to it.
• Cluttered code, sandwiched in an ugly way
• Pretty much all the Java warnings in the current code base
• Too much use of the "new" keyword instead of having a proper factory
• Writing to classes instead of interfaces - Confusing names for classes, functions, and variables. Things should be very clear and simple
• Confusing test names - Lack of testing for any production code. Ideally, our tests should cover 100% of the code base.
• Inconsistent formatting conventions. Tabs instead of spaces, wrong number of spaces for indentation, and so on
• Also, one of the worst things I usually encounter is hidden state. For example, you get hidden state in a Java class if the constructor declares a field that was not passed into the constructor. It makes the declaration hidden and the dependency obscure.