Skip to content

Project Clean Up

sguergachi edited this page Oct 15, 2012 · 9 revisions

Project: Clean Up

This is the wiki page used to coordinate the clean up and restructuring of the Aurora Core codebase.

Part 1: Re-Architecturing

Before we go in and comment and refactor each class, we need to take this opportunity to properly sub-divide and renaming classes to be simpler to work with as well as extend.

####Some Terminology before we start

  • Aurora Apps is the name of each item we select from the Carousel found in the Dashboard. These classes extend a class called AuroraApp which manages how the transision from and too these Aurora Apps work. Aurora Apps include the following classes currently: Aurora_GameLibrary, Aurora_Settings and Aurora_GamerProfile

  • Aurora Screens is the name of each screen a user is able to see and interact with in the app. This includes Aurora Apps but also the main screens currently under Aurora_Dashboard, Aurora_StartUp, AuroraLauncher ect.

####Classes that should be subdivided?

  • All Aurora Screens (Aurora_StartUp, Aurora_Dashboard, Aurora_GameLibrary, Aurora_Settings, Aurora_GamerProfile) need to be divided into at 3 seperate classes, one for UI components to be created and rendered on the AuroraCoreUI and one for the Logic which will proccess requests comming from the from the UI class associated with it directly as well as the 3rd commponent called the Handler commponent which contains all of the Listeners/Handlers form elements generated in the UI commponent.

  • InputHandler should actually be divided into the seperate Handler classes for each respectable

  • The UI Class element should have an abstract class used by UI classes that interact with the AuroraCoreUI This abstract class should have one method for creating all of the UI components and one for actually rendering the GUI on the AuroraCoreUI This abstract class will be called `

  • The class AuroraLauncher contains both the logic and the UI of the launch screen when a game is played. Even if AuroraLauncher has a UI independent of the AuroraCoreUI it should still be subdivided into the 3 components of the Aurora Screens.

  • The class AuroraMini which contains the UI and logic of the minimized UI of Aurora should also be subdivided in the same manner as the rest of the Aurora Screens.

Classes that should be renamed?

  • Subdividing all Aurora Screens into a UI class a Logic class and a Handler class will require a new naming convesions which will be as follows (example) : AuroraScreenName_UI, AuroraScreenName_LOGIC, AuroraScreenName_HANDLE

  • The previously named class AuroraUI is essentially the Canvas in which Classes such as the Dashboard use to "paint" their specific components on to of. It consists of all of the presistant UI elements that are likely always visible throughout the app. We should rename this class to represent what it acctually means: AuroraCoreUI

Part 2: Refactoring

Refactoring involves moving code around inside individual classes to more logical positions, renaming variables to be more human readable.

Code should have a flow, this involves no commenting. We need to make the code as readable and cohesive as possible without a single comment.

This will also mean we have to esstablish some sort of style guide, which will enable common practice in variable naming, way of presenting and stucturing code ect. This will of course tie in with Part 3: Commenting as a style guide will very much help esstablish how commenting should tie in with actuall coding.

Style Guide

First thing we need to do is follow the Java conventions throught the code:

Class organization: Java Conventions

Part 3: Commenting

We need to comment the codebase, simply put. The commenting has to follow a very simple and elegant flow. It should read like a book, be divided into chapters in sence. Here is an article regarding how commenting should be done. I think we should use this as a base line for how to do commenting well: http://antjanus.com/blog/web-design-tips/best-comment-separator/