Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Coding habits!

Author
Message
n00bstar
17
Years of Service
User Offline
Joined: 9th Feb 2004
Location: Montreal, Canada.
Posted: 7th Feb 2021 14:30
Because this forum is usually more question than conversation, I thought I'd try to spark a discussion that isn't about solving someone's problem

So tell us about your top 5 coding habits, good or bad...or at least what YOU consider good or bad. We can then be critical of each other's habits and decide if they're actually good or bad

Here we go...

1- My main loop is mostly free of code. (good I guess?)
Except for very basic core code (clearscreen, sync, stuff like that) my main loop is composed only of function calls. Sometimes I'll code in the main loop, but once I get my piece of code working, off into a function it goes. I like to be able to look at the entire logic structure of my applications easily. Helps me determine where stuff should go so it won't interfere and create bugs.

2- Everything is kept tidy. (that HAS to be good, right?)
Everything is indented. I can't stand looking at code that all starts on the first column, I think it makes it unreadable, especially if you take a long break from a project and come back to it later. Everything is commented. Not in super precise detail, but at least to give a general idea of what a code block is for. And finally, everything is stored in folds. When I know a particular block of code is solid as a good as it can be, I close the fold. That way the only open code is what I need to keep working on.

3- I can't stop debugging (that... I know is bad)
Maybe it's because I worked in QA for so long, but I have a very hard time with "good enough for now". When I implement a new feature, I will keep working on it until it is as small and efficient and bug-free as possible. This makes development rather slow overall.

4- I code functions like I was coding for someone else (good and bad)
If I need to display text somewhere... I'll code a function with tons of bells and whistles that I might not ever need. Size, color, rotation, font style, in-line codes, transparency, etc etc. I make them as versatile as possible. This makes my functions easily re-usable in other projects, but it also bloats them quite a bit and I often end up with functions that need 27 parameters to work

5- Separate everything into includes (that's good, for me at least)
I don't much like code that has 1000 functions all clustered at the bottom. I try to group stuff by theme and make a separate .agc file for everything. Main, Framework (where I store my quality-of-life stuff that reduce coding time, like assigning constants to keycodes for example), Audio, Graphics, Controls, GameLogic, etc. I find that I can then save myself a ton of reinventing the wheel by just importing those files into new projects.

So what's yours?
-----------------------------------------------------------------------------
We all got a chicken duck woman thing waiting for us
MadBit
Valued Member
Gold Codemaster
11
Years of Service
User Offline
Joined: 25th Jun 2009
Location: Germany
Posted: 7th Feb 2021 17:29
I'm getting into this discussion.

Here are my TOP 4
1. talk is silver, silence is gold ... commenting the code is everything.
I know that commenting the code is one of the most important things to simplify a programmer's life.
Especially in long and/or team projects it is very important. To keep the overview later on.
I myself rarely manage to do this.

2. Break a problem into many small problems.
This way you get a high degree of maintainability of the code. Corresponding functions are more likely to be reused in other areas.
Debugging is simplified. The process of solving the whole problem is faster. (my experience)

3. Reference instead of copy.
For functions that receive or output UDT's, I try to pass them by reference whenever possible.
I don't know how Agk handles this internally, but I think it just costs time when copies are made.

4. project organisation.
Before I start a project, I create a sensible uniform folder structure.
Like for example:
Project folder, Source folder, Media folder (media used by the running app), Working media folder (media in raw format that will be edited).
There are certainly more structures on how to organise your project but I hope you know what I mean.

About your top 5
1. i think it's good to make the main loop as small as possible but not smaller than necessary.
I think it's useless if there is only one function in the main loop but then all other functions are called from this function.

2. i think this is good, it partly coincides with my first point.

3. i like optimised code. If you have the time for it, I think it's fine.

4. i personally don't like that. Functions should not have too many parameters. This is the opposite of my point 2.

5. I completely agree.


Share your knowledge. It\'s a way to achieve immortality. (Tenzin Gyatso)
blink0k
Moderator
8
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 7th Feb 2021 20:21
What about encapsulation. How can i make functions & data so i can reuse code easily?
Loktofeit
User Banned
Posted: 7th Feb 2021 21:52
n00bstar. I code much the same way you do.

LynxJSA's web games/quizzes - LynxJSA's Android apps
AGK Resource Directory
"Stick to a single main loop (DO...LOOP) and loop through it every frame.
Do everything inside functions.
Use finite state machines to control your game.
Use lots and lots of source files.
Use virtual resolution instead of the default percentage system." - Digital Awakening
blink0k
Moderator
8
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 7th Feb 2021 22:44
i use #constants for those numbers
#constant GAMEMODE_SPLASH 0
#constant GAMEMODE_MENU 1
Makes it easier if you need to reference them elsewhere or change them
n00bstar
17
Years of Service
User Offline
Joined: 9th Feb 2004
Location: Montreal, Canada.
Posted: 7th Feb 2021 23:04 Edited at: 7th Feb 2021 23:04
MadBit wrote: "I myself rarely manage to do this."

Oh I know.. I've looked into the NuklearUI code! I had to buy a bunny and murder it in cold blood to appease my rage

MadBit wrote: "Like for example:
Project folder, Source folder, Media folder (media used by the running app), Working media folder (media in raw format that will be edited).
There are certainly more structures on how to organise your project but I hope you know what I mean."

Oh yeah! I further divide my media folder into gfx, sfx, dat, fnt etc etc. I also try to keep the same general structure for all my projects.

blink0k wrote: "What about encapsulation. How can i make functions & data so i can reuse code easily?"

I try to do that with all my includes. I like to be able to just #include something and not have to add anything to my main file to make it work. All the data and functions needed to make that particular code work is defined in the include. I usually need to add a InitThisPieceOfCode() function for stuff that isn't executed automatically upon being included, but otherwise it's already all done.

Loktofeit wrote: "n00bstar. I code much the same way you do."

Yep! Gotta love those main loops that just look like pseudocode.
-----------------------------------------------------------------------------
We all got a chicken duck woman thing waiting for us
smerf
16
Years of Service
User Offline
Joined: 24th Feb 2005
Location: nm usa
Posted: 8th Feb 2021 18:09
My personal preference for coding habits I always create an inblocked as soon as I open a block if and if. Always declare the integer type float string integer. I never worked inside of my main project folder ever. I include files for each large function and load them with include and then go sub to load their variables and return back to the main. I never make a global variable. All of my globals are specific to their include files and they are inside of a type. This allows you to organize and group your global variables inside of a type with a custom name that will prevent any kind of conflicts it also helps you to stay organized when coding and when you need to do some debugging or show something on the screen is easy to do some shorthand on the main file to print texts or to meet your condition or it's easy to create subroutines or drop in and out of loops based on condition. Always indent your code. A function should be created to where it can be reused in multiple locations the only way to do this is to not hard code anything let everything return its own ID. Or systematically generate IDs.

Groovacious_Claims
User Offline
Joined: 4th Jun 2020
Location:
Posted: 10th Feb 2021 16:21
1 - good : I try to write a fairly descriptive comment over every code block. I’ve had to restart too many projects after coming back to them and being lost!

2 - bad : I tend not to update those comments after making edits to code blocks. This leads to me having to have an occasional “reorganization day” where I read through the code and decrypt its functions into understandable text.

3 - good : I focus on hooking an SQL style database in to the project so that entities can be easily created/customized/removed. I believe my code should be an engine that various feeds are plugged into, and I am always working to achieve a state in my code where I will only have to manipulate my tools providing input in order to reach the desired output. This means extensive use of modular functions and types! If save states are needed, JSON is a great way to quickly serialize types.

4 - bad : I often spend too long coding the utilities. In my search to build a sexy engine, I can glaze over the point of “just getting it done”. Many of my projects are abandoned because my utility took the priority, at which point I name the utility after the game that could have been and pass its code to my next project. This is the case with my “command deck database system” that I wrote for a game called “command deck” that never made it past having a database and a start screen.

5 - good/bad : I enjoy trying different approaches to organizing my code in each project. I end up following a structure similar to noobstar, more or less, but take each project as a chance to attempt finding a more optimal structure. Each of my projects usually become slightly more efficient, but it can become hard to decipher old projects once I change enough conventions. Sticking to some core coding rules I set for myself is the key I believe, and I have recently been working on a sort of Standard Operating Procedure document for my games, just to keep myself focused on what’s important.

Thanks for the fun forum post I enjoy seeing everyone’s perspective/priorities.
Phaelax
DBPro Master
17
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 15th Feb 2021 02:57
How I want to code versus how I HAVE to code are two different things. My current job likes to give me quite demanding deadlines (and changes requirements constantly) and I usually end up writing code to get the job done and not necessarily in a well written manner. Recently, I finally had some breathing room to go back and refactor my code while adding some much needed comments before I forgot what stuff did. The only silver lining is I'm the only developer so how I manage projects is up to me.
Tiled TMX Importer V.2
XML Parser V.2
Base64 Encoder/Decoder
Purple Token - Free online hi-score database
Legend of Zelda

"I like offending people, because I think people who get offended should be offended." - Linus Torvalds
Raven
16
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 20th Feb 2021 00:19
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.
adambiser
AGK Developer
5
Years of Service
User Offline
Joined: 16th Sep 2015
Location: US
Posted: 20th Feb 2021 00:37
@Raven:
#2 - I studied CS and also hate prefixes except where absolutely necessary. They were more useful long ago, but nowadays not so much. IMO

#3 - I agree about types.
One place where I've noticed a huge performance hit in AppGameKit is using types as argument types because they are passed by value and everything in the instance gets copied before calling the method. Using ref speeds things up at the risk that the method can change the original.
What other performance hit are you meaning with types?
ruckertheron
4
Years of Service
User Offline
Joined: 12th Nov 2016
Location:
Posted: 4th Mar 2021 14:37

I try to limit the amount of numbers possible and use constants. I try to start with theory and then go to type.. Very important to me to establish some sort of hierarchy between data. No loose variables or non array variables should have to be global. I rather use select than a bunch of if conditions every time if I can. Also:




something like that

just a beginner here open to improve!
Phaelax
DBPro Master
17
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 6th Mar 2021 01:38
Quote: "1 • (Good) Declare EVERYTHING"

This! I'm not perfect, I make typos. I get annoyed by languages that allow dynamic variables!


Quote: "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"


I'm right there with you. I began writing a music app in java 15 years ago. I take a break, learn stuff, come back and realize I can do it better. I've rewritten it at least 3x times now, it's never going to get done!
Tiled TMX Importer V.2
XML Parser V.2
Base64 Encoder/Decoder
Purple Token - Free online hi-score database
Legend of Zelda

"I like offending people, because I think people who get offended should be offended." - Linus Torvalds

Login to post a reply

Server time is: 2021-04-10 22:28:46
Your offset time is: 2021-04-10 22:28:46