All code must be tested by multiple developers.
This means that when one developer writes code, it is tested once by the original developer, a second time by a second developer who also writes the documentation, and a third time by a third developer who verifies the documentation. All three developers have power to suggest and implement changes to the code.
All code must be properly formatted with spaces between blocks of code performing different functions.
This improves code legibility. A code block can be anything from a single line to 200 lines of code, whose function can be identified with a single comment such as “Send an email”, or “Format the XML document”. The objective is to make a developer take a quick look at the code and recognize what the block they are looking at is supposed to do.
Endeavour to write code once.
If a similar function is needed in multiple places, extrapolate it as a function and use variables to determine the code differences. These variables can be hardcoded situationally and force the code to run through if statements or switch statements to determine minor separate code paths. If, when looking at 3 methods, more than 50% of the code is identical, a function should be written. This calculation does not include variable names, attribute names, or any input value as differences.
Always include Exception Handlers
This is so important that failure to include exception handlers on an ongoing basis is grounds for dismissal. When exceptions are unhandled, any minor fault could cause the application to crash. This could be done by including a space in a string that is not supposed to have spaces. Instead, all GreatIdeaz code is written inside of try/catch statements that locate, handle, and log errors when they occur.
Three developers
When possible, GreatIdeaz employs three developers when writing code. The first developer writes the code, the second tests the code and the third will document the code. All three developers must agree that the code is formatted correctly and functional, that the tests are complete, and that the documentation is accurate. Any disputes are resolved through logical discussion, or in the most extreme case, a fourth developer who analyzes the code, tests and documentation and makes their own decision. Disputes and discussion are a good thing. Progress can’t be made without change.
When writing code, questions come up regarding previous solutions. Valid answers include any explanations of solutions to previous problems including work arounds or best possible solutions. When asking questions, answers such as “We have always done it this way”, or “There was a reason before so we should still do it that way” are invalid answers. They reject change for the sake of maintaining an old system. The only other valid answer is “Currently not worth the time and cost to change”. Make a note of the suggestion and we may implement it in the future when reworking the functionality.
