Skip to content

Tips for developers

Jump to bottom
ThomasAngel edited this page Jan 24, 2024 · 2 revisions

Tips for developers

Note: These tips are a mix of Overthrow specific things and just SQF things in general. These are also not guidelines that you must follow to get a pull request to go through here, but I'd greatly appreciate it if you read this article before writing one. Overthrow is a mess and will probably always be, but we can make it more bearable one update at a time.

Commits and pull requests

  • Make commits that only do one thing. It doesn't matter if its over multiple files, as long as it's doing the same thing in all of them.

  • Keep pull requests short and sweet. So instead of "Complete rewrite of all the code", make a pull request more like "Rewrite file x".

  • Explain what you have included in the pull request and why. Undocumented changes will usually result in discussion, which will delay the merge a lot.

Assertions and debugging

  • Start the game with -debug enabled when developing / investigating an issue. This will show errors on screen while playing and add callstacks to the .rpt file, which is very useful for finding out what's wrong.

  • When writing code, using assert can be highly beneficial for debugging later on. If you anticipate that something can go wrong (like function input), consider writing an assertion so that the callstack will be provided when something does go wrong. This is a 100 times more helpful than a log message saying "something is wrong". This is worth the 5 microseconds of overhead that the assertion will add.

  • You can add extra logging using preprocessor macros. This is a bit of an advanced topic so I won't cover it in detail, see example below.

  • Example: https://github.com/rekterakathom/Overthrow/blob/master/addons/overthrow_main/functions/cleanup/fn_cleanupVehicle.sqf

Documentation

  • Add headers to your functions if you can, include things like a brief description, inputs and outputs

Performance

  • Write first, optimize later.

  • Consider how much your code will be run, and optimize based on that. If it's called 10 times per frame, optimize it thoroughly. If it runs once an hour, it doesn't really matter.

Clone this wiki locally