PT Forum

n00bstar 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?

MadBit 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.

blink0k 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 Joined: 21st Jan 2009
Location: Sarasota, FL

Posted: 7th Feb 2021 21:52

n00bstar. I code much the same way you do.

blink0k 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 Joined: 9th Feb 2004
Location: Montreal, Canada.

Posted: 7th Feb 2021 23:04

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

here 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.

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.

n00bstar. I code much the same way you do.

Yep! Gotta love those main loops that just look like pseudocode.

smerf 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 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 Joined: 16th Apr 2003
Location: Metropia

Posted: 15th Feb 2021 2: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.

Raven Joined: 23rd Mar 2005
Location: Hertfordshire, England

Posted: 20th Feb 2021 0: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 Joined: 16th Sep 2015
Location: US

Posted: 20th Feb 2021 0: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 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:

+ Code Snippet


Type CameraControlData
	Camera as CameraData
	Input as InputData
	
endtype





Type EnvironmentSettings
	Water as WaterSettings[]
	Sky as SkySettings
	Time as TimeSettings
	Weather as WeatherSettings[]
	Icon as IconData
	Tab as TabData
Endtype
	Type WaterSettings
		Object as ObjectData0[]
		Height as float
		Flag as integer
		Shader as ShaderData
		Transform as TransformData		
	Endtype
	Type SkySettings
		Object as ObjectData0
		CloudIntensity as float
		Flag as integer
		Shader as ShaderData
		Transform as TransformData
	Endtype
	Type TimeSettings
		Year as integer
		Month as integer
		Day as integer
		Hour as integer
		Minute as integer
		Second as integer
		PlaySpeed as float
		PlayStatus as integer
	Endtype
	Type WeatherSettings
		Particle as ParticleData[]
		SnowFlag as integer
		SnowVelocity as float
		SnowPattern as string
		RainFlag as integer
		RainVelocity as float
		RainPattern as string
		Temperature as float
		Humidity as float
		Precipitation as float
		WindSpeed as float
		WindDirection as Vector3Data
		Object as ObjectData0[]
		BoundingRadius as float
	Endtype
	Type IconData
		Name as string
		imgID as integer
		sprID as integer
		Transform as TransformData
		Flag as integer
		Status as integer
		imgFilename as string
	Endtype
	Type TabData
		Name as string
		Text as TextData[]
		Sprite as SpriteData[]
		EditBox as EditboxData[]
	Endtype
		Type TextData
			ID as integer
			Transform as TransformData
			DString as string
			Animation as AnimationData
			Font as FontData
			Color as ColorData
		endType
		Type SpriteData
			ID as integer
			Transform as TransformData
			Image as ImageData[]
			Animation as AnimationData
			Font as FontData
			Color as ColorData
			Shader as ShaderData
		EndType
		Type EditboxData
			ID as integer
			Transform as TransformData
			Image as ImageData[]
			Font as FontData
			Color as ColorData
		EndType
		Type ParticleData
			ID as integer
			Transform as TransformData	
			TransparencyFlag as integer
			ActiveFlag as integer
			Maximum as float
			Image as ImageData
			Frequency as float
			LifeSeconds as float
			DirectionalRange as Vector2Data
			Direction as Vector3Data
			Force as ParticleForceData
			StartZone as float[5]
			ColorKeyFrame as KeyFrameData[]
			ScaleKeyFrame as ScaleKeyFrame[]
		endtype
		type KeyFrameData
			SecondMarker as float
			Color as ColorData
		endtype
		type ScaleKeyFrame
			SecondMarker as float
			scale as float
		Endtype
		Type ParticleForceData
			Start as float
			Finish as float
			Transform as TransformData
		EndType
			

		Type ObjectData0
			ID as integer
			Transform as TransformData
			Mesh as MeshData[]
			Texture as TextureData[]
			Bone as BoneData0[]
			Child as ChildData[]
			Animation as AnimationData[]
			TransparencyFlag as integer
			Species as string
			SourceObjID as integer
			CollisionShape as string
			CullFlag as integer
			CollisionFlag as integer
			ShadowFlag as integer
			Shader as ShaderData
			Color as ColorData
		EndType
		
		Type MeshData
			Name as string
			Alias as string
			U as float[7]
			V as float[7]
			Image as ImageData[7]
			Shader as ShaderData
			VisibleFlag as integer
			ShadowFlag as integer
		Endtype

		type TextureData
			Name as string
			Alias as string
			Image as ImageData
		Endtype
		Type BoneData0
			Transform as TransformData
		EndType
		Type ChildData
			Object as ObjectData0[]
		EndType
		Type InputData
			Mouse as MouseData
			Key as KeyData[]
		EndType
		Type SelectionData
			Object as ObjectData0[]
			Image as ImageData[]
			Sprite as SpriteData[]
			EditBox as EditBoxData[]
			Particle as ParticleData[]
			Light as LightData[]
			Icon as IconData[]
		EndType
		Type ColorData
			Red as integer
			Green as integer
			Blue as integer
			Alpha as integer
		Endtype
		Type ImageData
			Filename as string
			ID as integer
		Endtype
		Type AnimationData
			Flag as integer
			Tick as integer
			TickLimit as integer
			Action as integer
			Facing as integer
			Frame as integer
			Image as ImageData[]
			DString as string[]
			Name as string
			TotalFrames as integer
			CurrentAnimation as integer
			
			AI as AIData[]
		Endtype
		Type FontData
			FileName as string
			ID as integer
		endType
		Type ShaderData
			ID as integer
			ShaderFileName as string
			Flag as integer
		EndType
		Type TransformData
			Pos as Vector3Data
			Angle as Vector3Data
			Size as Vector3Data
			Visible as integer
		Endtype
		type MouseData
			Transform as TransformData
			ClickState as integer[2]
			Offset as Vector2Data
			Difference as Vector2Data
		Endtype
		Type KeyData
			Value as integer
		endtype

		type LightData
			ID as integer
			Mode as string
			Radius as float
			SunFlag as integer
			AmbientColor as ColorData
			Color as ColorData
			SunColor as ColorData
			SunDirection as Vector3Data
		endtype

		type CameraData
			ID as integer
			Transform as TransformData					
			Image as ImageData
			Aspect as float
			FieldOfView as float
			Range as float[1]
			OrthoWidth as float
			OffCenterFlag as integer
			LookAt as Vector3Data
			Bounds as integer[3]
			Animation as AnimationData
		endtype
		type AIData
			Name as string
			Command as CommandData[]
		endtype
		type CommandData
			Name as string
			Transform as TransformData[]
		endtype
		Type Vector2Data
			X as float
			Y as float
		Endtype
		Type Vector3Data
			X as float
			Y as float
			Z as float
		Endtype

type myGizmo
	objID as integer[3]
	obj as integer
	selectedaxis as integer	
	cloneID as integer[3]
	transformFlag as integer
	selectedobject as integer
	grabbed as integer
	pobj as integer
	pobj2 as integer
	counter as integer
	switch as integer
	transformtxtID as integer
	transformsprID as integer
	transformimgID as integer[3]
	snapFlag as integer
endtype

something like that

just a beginner here open to improve!

Phaelax Joined: 16th Apr 2003
Location: Metropia

Posted: 6th Mar 2021 1:38

1 ? (Good) Declare EVERYTHING

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

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!

<1 >

Sign In