Coding Standards

h1. Coding Standards

Bearing in mind the desire to remove CBA dependency on the client.

h2. Documentation

• Use NaturalDocs formatting to document your functions
• Peer review code and put in the NaturalDocs function header - "Peer review: Wolffy 24/10/12"

h2. Sanity Checking

• Use CBA ASSERTS to validate data before progressing
• Ideally for every function, use ASSERTS to validate input parameters and output results

h2. Functions

• Use ALIVE_fnc_xxx for your function definitions
• Always use fnc_xxx.sqf for your function file names

h2. Test Harnesses

• Integrate Test scripts to automate testing inherent to the development process
• When bug fixing, modify the test script first to identify the bug, fix the bug, re-run test script
• CBA_fnc_test for testing frameworks

h2. Object Orientation

• Use Object Oriented SQF in preparation of the move to Java in A3
• Utilise inheritance/reuse of existing code, wherever possible from a parent class using object orientation

h2. Important readings

• http://community.bistudio.com/wiki/Biki2.0:Performance_Considerations
• http://community.bistudio.com/wiki/Code_Optimisation

h2. Good Practice

• Embrace CBA use of Macros
• Embrace CBA use of function wrappers
• CBA_fnc_debug/error/log and associated MACROs for debug level messages
• Avoid execVM/spawn where possible
• Move all initialisation code/messaging into the module directory
• Avoid global variables - if you want to share a variable, use setVariable on a server side game logic as this allows for multiple instances of the same module.
• Wherever possible use stringtable.xml files to allow multiple languages.
• CBA_fnc_benchmarkFunction for function profiling (not sure how useful this function is) rule of thumb: Avoid loops! rule of thumb 2: non critical operations that have a "near" end, can be scheduled but critical operations (like animations, or things where you need an exact execution) must be handled within one frame. rule of thumb 3: Its better to handle code in un-scheduled space because you have direct control over it and it isnt impacted by "engine laziness", as in "waiting" for the next operation to happen. rule of thumb 4: You know that your code is executed non-scheduled, if waituntil and sleep _time; (within the code you want to execute) doesnt work and an appropriate error is logged to RPT! rule of thumb 5: If you want to process too much data in one frame or you overload the schedular then the game engine freezes for a moment, try to split the operations on several frames then.
• Order of CPU hog for object/unit collection with near.../nearest...:

1. nearestObjects
2. nearestObject
3. nearObjects
4. nearEntities (doesnt work for buildings, i believe only for units/vehicles) PS: Those are my personal expierences, i may be wrong in some points and happy to be corrected.