Yeah, im preaty sure that it will end up being writen entirely in BMX. Writing C++ and compiling with MinGW or linking with a lib file, etc cant be debuged, a total turn off.
The only think that will bug me is that operators can be used on custom types (sucking majorly).
Why dont I just go out on a whim and define my coding standard as a basis. Please comment on this if there are issues for anyone that will be working on this project.
- Conditional statements
-- A blank line must be included after a conditional statements.
-- Tabbing will increment (tabs must be used for indentation, not spaces) after that line
-- A blank line does not follow a conditional statements end.
- Commenting
-- commenting for a single line will be all in lower case and preceed the statement it will reffer to.
-- single line comments must be in the same indentation as the code line they reffer to.
-- commenting for a function or data type will be done with a comment block as follows:
-- The comment block must be placed at the same intentation as the declaration that it applies to.
- Significant code
-- significant blocks of code can be seporated by a blank line preseeding and following the block.
-- extreemly significant code can prefixed with a comment block.
well I guess that sorts out the formating and layout of the source code (if anyone has beef with it then just shout :). Im no good at naming conventions because I generaly make them up on the spot for whatever mood im in. They will become very important as the project grows and especialy for maths routines (without operators >:).
we need something like constants are all capital. Types have capitals for each word in there name. Members start of lower case (java anyone :) and then follow type rule. local and global variables are all lower case (hmmm).
Thats just my thoughts though and imo looks nice and neat.
The only think that will bug me is that operators can be used on custom types (sucking majorly).
Why dont I just go out on a whim and define my coding standard as a basis. Please comment on this if there are issues for anyone that will be working on this project.
- Conditional statements
-- A blank line must be included after a conditional statements.
-- Tabbing will increment (tabs must be used for indentation, not spaces) after that line
-- A blank line does not follow a conditional statements end.
- Commenting
-- commenting for a single line will be all in lower case and preceed the statement it will reffer to.
-- single line comments must be in the same indentation as the code line they reffer to.
-- commenting for a function or data type will be done with a comment block as follows:
'/** ' * COMMENT HEADER ' * descriptive comment text ' * that spanns multiple lines ' */
-- The comment block must be placed at the same intentation as the declaration that it applies to.
- Significant code
-- significant blocks of code can be seporated by a blank line preseeding and following the block.
-- extreemly significant code can prefixed with a comment block.
well I guess that sorts out the formating and layout of the source code (if anyone has beef with it then just shout :). Im no good at naming conventions because I generaly make them up on the spot for whatever mood im in. They will become very important as the project grows and especialy for maths routines (without operators >:).
we need something like constants are all capital. Types have capitals for each word in there name. Members start of lower case (java anyone :) and then follow type rule. local and global variables are all lower case (hmmm).
Thats just my thoughts though and imo looks nice and neat.