Best Coding Practices

• So you want to write a MOD that is wonderful and it deserves to be included in the released code?

Our 140,000+ user community expects the official released bot to be bullet proof and operate without errors, or at least self correcting for any minor errors that occur and keep farming 24/7. The development team will usually test all hotfix code on least 5 PC, and major code releases on least 30 different PC's including all supported OS, VMware emulator, and on several VPS. We do this to ensure the minimum number of problems.

• Download and use the full SciTE editor

The normal AutoIt install package has a reduce feature version of the SciTE editor included. The full editor has vastly improved capabilities including: code tracing, break points, Tidy capability, and automatic UDF creation.

• Protect the copyright

There are a lot of AutoIt based Clash of Clans bots. MyBot is the original. Often copied, cloned, stolen, or imitated, but there is only one MyBot! To keep it this way and help you receive credit for the code you write and contribute to the community, you must include a comment header with appropriate legal information. The full SciTE editor has the ability to automatically add a User Developed Function (UDF) header and give you a place to describe your code functions. The basic UDF with the MyBot copyright added is below. Please use this for all functions, including the custom Remarks Copyright as shown. If you are a prolific AutoIt coder, you are welcome to add whatever copyright message your lawyer suggests. But if do use a special copyright, CGB cannot and will not use the code function without written permission. If you like more information on the AutoIt UDF specification, check out this page in the Wiki: https://www.autoitscript.com/wiki/UDF-spec

• Use the AutoIt Tidy function on all new file

The tidy program is available as a separate AutoIt download or built inside of the SciTE full editor. It will automatically reset all indents, adjust code spacing, and comments to make the code more readable by others. Note - MyBot does not use Tidy on the GUI files as they need some special formatting or it is too easy to get lost.

• Please include comments in your code

Many of the older bot files have zero comments. A couple of "retired" developers did this to make it harder for others to change "THEIR" code. Please do not do this. Besides the use of the UDF header to outline function descriptions, and variables used and returned, please add a few comments inside your code to let others know what you are trying to do. You do not need a comment on every line or command. But the longer the function is, the more it would help others if you tell us what is supposed to happen, especially with complicated code sections.

• Do not use GUICtrlRead() command inside functions

Since the entire GUI is disabled when the bot is running (except the pause and stop buttons), there is absolutely no reason to repeatedly use the GUICtrlRead function. The faster best practice is to use a global variable to store the state of the GUI button/checkbox/combobox/etc. These assignments should be done in the CGB GUI Control XXX.au3 files for the tab where the control is located. Some older GUI variable assignments are located in the save/read/apply Config files, and for variables that do not change very often, this is also acceptable as the config is saved/applied with every start.

• Error Proofing

Because you are writing code to interact with a dynamic window controlled by the CoC APP and BS, you never really know what is on the screen. Sad So error proofing is required to ensure the code works as intended not matter what the User, PC, or any other outside force has done.
Let's be honest, there are many examples of how NOT to error proof scattered all through legacy code. The developers are constantly fixing bugs created by "blind" clicking, assuming window never changes, or that error windows never appear. Smile One good example is the use of error proofing is the various "click" functions. Before the bot clicks, you need to make sure that is clicking the intended target. If you want to click a button, use pixel check (faster) or image search (slow) to make sure the button exists. If the PC is too slow/fast, then your target may not exist and when you click and you may end up deploying troops instead of hitting a button. This especially important when clicking on any button that has the potential to use resources. If you resources are low, then CoC will open a window asking you want to use GEMS to keep going. There is a special GemClick function written for non-time sensitive clicks to avoid this issue, and there is also a TrainClick function for troop training optimized for speed and safety. Both of these are good examples of how to use error proofing. Another problem area is using pixel checking for shades of green. Since the entire base is on a green grass, variations in base layout can mean your check for green pixel has a false positive and finds grass and not a button! Sad If you are doing any pixel checks, you must realize that the pixel check tolerance values are simply +/- integer value range of the RGB values for the color. So before you pick any pixel color check, look at the RGB values of the normal & not normal values to ensure the tolerance is set correctly. In some cases you may need to check several pixels to ensure you have the intended feature. Another common issue that requires error proofing is waiting for actions like; window closing, window opening, or even built in CoC messages to clear the screen before the code moves to the next task. The standard method is to add a simple delay using sleep (the bot has a special sleep command, more later). But if the PC is too slow/fast then the delay time may not be right. A better practice is use a simple While/WEnd loop that is looking for the action to complete or the next window to be ready.

• Delay or Sleep commands

Background - AutoIt is single threaded language. Only one command can occur at a time. This means that AutoIt does not have true interrupt driven capability, and the interrupt functionality has to be coded into the program scripts. There are 2 objects the user touches that makes it look like it interrupts the bot operation, Stop, and Pause. But these buttons are not true interrupts, but are are merely button states the bot reads occasionally when there is "extra" time. This extra time is whenever the script is in a "_sleep()" command. If your script does not use the _Sleep() function and uses the native AutoIt sleep() function, then our 2 buttons will not behave as expected! The proper method to add a script delay is: If _Sleep(delay time in milliseconds) Then Return The If/Then method allows for the sleep time to properly stop the bot with false return value.
If your code doesn't need really any delays, then the best practice is to add short 50-100ms delay after commands where a small delay has no impact on operation. Examples of the best place to add these delays for improved stop/pause button response are: after every setlog, after clicking a button, and/or when waiting for windows to open or close.

• Variables

We try to follow the AutoIt Best practices ( https://www.autoitscript.com/wiki/Best_coding_practices ) for variables. The only place we are radically different, is we treat all variable scope as local scope, even if it is global bot variable (read the AutoIt wiki on variable scope for more information). To avoid having functions declare the same variable names please place all global variables in the GlobalVariables.au3 file in the \COCBot folder. Also, While AutoIt will let you add "Local" or "DIM" statement anywhere, please not make others look for your declared variables. All local variables should be declared at the top of the function. The developers have not turned on the AutoIt "Must declare" compile feature as we still have a lot of legacy code to clean up first, but it will be used at a later date.

• Debug Tool

Starting with V3.1, the developers added several flag variables specifically for debug purposes. Examples of these are $debugSearchArea, $debugOcr, $debugRedArea, $debugSetlog, and $debugClick. Several are for debug of our Proprietary DLL codes ($debugSearchArea, $debugOcr, and $debugRedArea). These enable us to get extra debug information when they are set equal to one. The $debugClick variable can be enabled via the expert tab in the GUI to enable users to quickly see what location the bot is clicking when they have issues. The most useful of the the debug flags for MOD writers is $debugSetlog. When $debugSetlog is turned on (set equal to one), then these extra log messages can be seen. Anyone writing a MOD is encouraged to add extra log messages that would help with finding bugs or user errors. Common places for debug log messages are to check variable values, display pixel colors, or just to say code is "stuck in this loop due an error". During 1st pass of new feature development there may be a lot of these messages