How I program in AppGameKit Script is honestly VERY different to how I prefer to usually program in C++., and a lot of that comes from constantly experimenting to see what has the best performance for the least time.
But there are some habits that I do carry over.
1 • (Good) Declare EVERYTHING • It's always a good habit to ensure that every variable used is Declared and Initialised before usage... this especially comes into play regarding my second habit
2 • (Good / Bad) Descriptive Naming • To me a Variable, Function, etc. essentially needs to be named what it does. Now this is a good habit as often you might not have time, or just don't remember to Comment Code to explain what things are doing; so being able to look at something and go "Oh THATS! What it's being used for" is great., esp. if like me you have the memory of a goldfish... now why I say this is bad, is because it's also generally good practise to use a single letter convention to also denote the data type.
i.e. bMySwitch for a Boolean (True / False Integer), iMyValue (Integer), dMyValue (Dword / Unsigned Integer), fMovementX (Float), MyType_t (type), arUserFiles (Array), etc.
But I also tend not to bother in C++ either... drives those who I do collaborative projects with crazy., but then I didn't learn to program in CompSci at University / College... so never had that behaviour brow beaten into me.
3 • (Good / Bad) You get a Type... You get a Type... EVERYONE GETS A TYPE • So, yeah... anyone whose oft seen the Demo / Sample code I throw up, will have noticed that I use Types for almost everything., and actually it's also pretty easy to spot contributions I do on GitHub as suddenly there will be a comprehensive Class instead of ANY Struct or Discreet Variables.
Now on the one had this is Good, because it keeps the code clean; and actually in C++ it's better because Classes essentially take over the role of basically all Object Elements from C... but in AppGameKit Script this is a bad thing, because it does have an effect on performance.
This said I just can't give up that it not only keeps the code clean, but it also ensures all important variables are grouped together; not just named similar.
4 • (Good / Bad) Includes • So, here's a weird one... in Dark BASIC Professional and C++, the way I tend to program is I write everything in the Main.dba / Main.cpp; but then later I'll take everything related and put it in it's own include File(s).
This is fairly standard practise for C++., you create an Interface (personally I use Namespace and Classes) and then you break it down into Definitions (.h) and Programs (.cpp); technically you can just have it all in a single .cpp or .h and that's enough; it somewhat depend on how you want to have it accessible by others.
With DBP., well you'd just cram everything into a single source include; but as I've explained in the DBP Forum... you'd encapsulate Definitions with a GoTo Label; allowing you to include and declare everything for usage.
It's just a shame DBP doesn't have #pragma once Compiler Definition Flag., as it'd be great to include what you need (without needing another include file) that are common, but obviously once it's defined you don't want to crash things by having it defined again.
Ultimately what I did with DBP was create a "Standard Library" (so-to-speak) that I'd typically include in a new project.
AGK however., eh it doesn't really encourage using includes much; and I've found myself simply NEVER using them in it.
Sure; this means massively long single source projects but the problem is that there is no support for nestled #include or #insert... and, well it's just a bit too strange breaking things down to Definitions, Types, Functions, etc. which you kind of have to do.
I mean as a whole it feels like this feature was included as an after-thought; when really they should've expanded on what DBP did (but then there are A LOT of areas that's true for AppGameKit Script)
5 • (Bad) Never stop improving... • This might not sound like a bad thing., but essentially I have a nasty habit of going back and entirely rewriting things to constantly improve them; either in terms of performance, versatility, etc. It somewhat stems from working in Team Projects; as well the Team themselves will typically take what you've produced and just run with it, while agreeing what is needed next; so you never really get time to go back to your code and you get in the habit of "If it works... it stays..." regardless of how Pretty or Performant it is. Where-as when I'm working on a project on my own., I'm ALWAYS returning to previous code, thinking "Oh I can do that better!"
Realistically for a Project to actually advance, you eventually have to say "Alright, that's GOOD ENOUGH... let's move on!" but it's just something I can't really do if left to my own devices.
I'm the same when it comes to Art... unless there's a clear deadline., I'm always tinkering or simply scrapping something perfectly good to redo it.
You simply can't be a perfectionist if you want to complete a project.
