dev best practices

BestPracticeId	Name	Description
1	File units	The main code unit is a file - whenevere possible use 1 file for 1 perl module , 1 file for one class , 1 file for one table , 1 file for 1 foreign key
2	File unit test	Each file unit should have its own test unit(s). For example a create table statement should end with the test with whether or not the table was really created
3	File units documentation	Each file unit should have documentation describing its purpose , version history and relation to another file units
4	comments per run line	Each run line which is not obviously should have a comment
5	One space for readability and parsing	In order to improve the readability of the code and potential parsing after each token or operator one and only space should be set - Thus any potential parsing of the log output will be easier as well
6	The beuaty of the code	The code has to be formatted and written so well, that the potential user using and expanding it would understand the purpose of the code at a glance and engange in expanding the code base
7	Tab sizes	2 is too much , 4 is too less - remember to set the option convert tabs to spaces in your texteditor
8	2 lines between functions and subs	The number between the subs and functions should be permanent - 2 lines at minimum
9	Short doc for functions and subs	Each sub and function should have at leas 1 line of documentation describing the purpose of it
10	docs at the end	Place the file unit documentation at the end. Place the file version at the top and a VersionHistory at the end - thus each time you compare two files with the same name from different product instances even if they are in the same version ( the products ) you could distinguish the files
11	always test run after changing a code unit	Do not change code units without actually immidiately testing afterwards the implications of the change even if they are very small changes - formatting etc. Since even the smallest change could brake everything
12	program error paths first	Should you introduce a new expected variable - file etc. Program first the error control flow paths - e.g. what to do if the file does not exist
13	Stub refactoring	Start stub refactoring from a tested stub or template, use the old code unit(s) for copy paste the logic and refactor on top of the stub / template