+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2)
+--- Thread: Coding Styles (/showthread.php?tid=2920)
Coding Styles - Pete - 08-09-2024
One of the things I love most about BASIC is the flexibility to code in various styles including declaring or not declaring variable types. This saved me a bunch of time back in the early days when memory was at a premium. I would use single letter variables, and DEFINT at the top of each program to assign A-G as variable length strings, H-P as integers, and other letters for long, double, etc. as needed. Also making most if not all of your variables integer types was an important for speed back in the day. There is also the choice to pass variables to sub routines as global variables. I did that almost exclusively. It sure takes the work out of passing a long laundry list of variables to several sub routines. The best compromise between these two methods, I think, is using UDT's, except, of course if you are heavy into arrays. I wish those could be supported some day, but, anyway, I found it much easier to pass UDT's in sub calls, as the whole grouping gets passed instead of typing out each passed variable.
So, anyone want to chime in on what they have found to be helpful coding styles for their projects? Maybe how and why you evolved to the way you code today, etc? It might make for a fun discussion thread, and a nice reference to help share knowledge.
Pete
RE: Coding Styles - SpriggsySpriggs - 08-09-2024
I like to code like a C coder. Declaring everything explicitly, avoiding temp variables when possible, and using semi-descriptive names for the variables. I also like to have all my constant declarations before everything else. Then the UDTs. Then the DECLARE LIBRARY sections. Depending on whether or not the program is large, I even like to have a "main" sub/function that is called in the code rather than just naked code in the main body. Constants are always SCREAMING_SNAKE case. Functions and subs are always UpperCamelCase. Variables are lowerCamelCase. BM files always contain only functions. BI files only contain declarations. If the program doesn't need any graphics, it will always be a console program. If a task can be performed using an external library, I will use that first before trying to reinvent the wheel.
RE: Coding Styles - Pete - 08-09-2024
I'm always reinventing the wheel. I have a round one I'm expecting completion on sometime in the late summer of 2035. That said, awhile back I started making my own libraries, but I have to admit, it is tough to just get them to play nice with other new stuff I code. Rather than keep trying to iron out ways to make them universal, I just bite the bullet, go plenty of those, and adapt the code.
Right now I'm pulling out my hair to decide whether to go back to using global arrays or continue slugging through trying to remember them and pass only what's needed to each subroutine.
In regard to finding gosub and sub calls in my code, I simply leave a line space above the call...
Code: (Select All)
For i = 1 to 5
PRINT i
NEXT
Gosub whatever
Print "Finished"
ENDTo call a subroutine, I used to use the CALL statement. Now I prefer not to, but I need the line space to help me find them, as I can't rely on doing a SEARCH for the CALL statement, anymore. Which reminds me how important naming is if you intend to rely on using the SEARCH feature to find out where you are in the code. For example, you could do: DIM a as integer, but it is far easier to name it a% if you have to find each and every one of them in a routine that has several phrases or remark statements where the single letter a appears. Search "whole word" is of no use in this instance.
Pete
RE: Coding Styles - bplus - 08-09-2024
I am curious on other peoples thoughts on drawing the line between using a GoSub and a full blown Sub.
My rule it should be a full blown Sub if there is any chance the Sub might be used in other apps but when in doubt just go Sub.
GoSubs best for applications very specific for the code you ar working. This issues should be decided before Constants and Shared, that is if we are actually thinking ahead a little
RE: Coding Styles - Pete - 08-09-2024
I use subs almost exclusively for a major portion of a routine and the sub could easily be made into a stand along routine like a popup window. So even if there is only one call to the routine, I'll still make it as a subroutine, rather in code it inline. I use GOSUB for any short duplicated routine. If I had a help program that needed several places in the code to print "My Assistant found this to be your best possible solution: " well, that would be coded as: GOSUB MyAss
Pete
RE: Coding Styles - TerryRitchie - 08-09-2024
(08-09-2024, 03:21 PM)SpriggsySpriggs Wrote: I like to code like a C coder. Declaring everything explicitly, avoiding temp variables when possible, and using semi-descriptive names for the variables. I also like to have all my constant declarations before everything else. Then the UDTs. Then the DECLARE LIBRARY sections. Depending on whether or not the program is large, I even like to have a "main" sub/function that is called in the code rather than just naked code in the main body. Constants are always SCREAMING_SNAKE case. Functions and subs are always UpperCamelCase. Variables are lowerCamelCase. BM files always contain only functions. BI files only contain declarations. If the program doesn't need any graphics, it will always be a console program. If a task can be performed using an external library, I will use that first before trying to reinvent the wheel.Spriggsy's use cases are pretty much identical to mine. Of course I comment the crap out of everything too.
One thing I've started doing more of lately is prefacing variables with 3 lowercase letters do identify their use (there is a term for this but can't remember it now).
sndScreaming& ' a sound file
imgBigHead& ' an image file
sprMario% ' a sprite handle
When it comes to UDTs and variables I always share them at the sub/function level.
TYPE TYPE_SPRITEDB ' sprite definition
ptrHimg AS INTEGER ' pointer to image database (handle)
ptrHsnd AS INTEGER ' pointer to sound database (handle)
..
END TYPE
...
...
REDIM SpriteDB(0) AS TYPE_SPRITEDB ' sprite database
REDIM SoundDB(0) AS TYPE_SOUNDDB ' sound database
REDIM ImageDB(0) AS TYPE_IMAGEDB ' image database
SUB MySub(...)
SHARED SpriteDB() AS TYPE_SPRITEDB ' need access to the sprite database
SHARED ImageDB() AS TYPE_IMAGEDB ' need access to the image database
END SUB
I always try to stick with the UDT naming convention I used above as well. This makes it easy for me to remember their names.
By using SHARED within subs/functions I've found it easier to identify exactly which variables the sub/function will use and/or affect.
For really big projects I'll make a "dummy" sub or function that I can copy/paste and then rename that contains all of the shared declarations that can exist. I then simply delete the declarations that are not needed after I have finished with the sub/function code.
RE: Coding Styles - SpriggsySpriggs - 08-09-2024
Oh, I forgot. I also hate suffixes. I absolutely abhor them.
RE: Coding Styles - Jack - 08-09-2024
I am inclined to closely follow the original Pascal convention
constant declaration
type declaration
function/sub declaration
main:
constant declaration
variable declaration
main code
suffixes have their place in my opinion, for example to distinguish between functions of different result type
but I hate overuse of the var statement, actually, I avoid it's use if at all possible, QB64 doesn't have the var statement but some languages do
var is used to declare a variable type on the fly depending on what type is on the right side
for example: var s="hello"
s would be declared as type string and then assigned the string "hello", but quite often it's impossible to infer the variable type assigned to the variable on the left, for example: var s=some_windows_api(...)
also the fact that it's used anywhere in the code instead of the variable having been declared at the top
<edit> @SpriggsySpriggs , variable suffixes I hate also, when I wrote to "distinguish between functions of different result type" I wasn't thinking of the basic suffixes like $#%&, almost looks like a curse word
RE: Coding Styles - Jack - 08-09-2024
subroutines are ok but only if you self impose some restrictions, only one entry point, no goto into some other subroutine, no goto outside the subroutine , clearly comment it's entry point and what variables are affected
RE: Coding Styles - TerryRitchie - 08-09-2024
(08-09-2024, 06:40 PM)SpriggsySpriggs Wrote: Oh, I forgot. I also hate suffixes. I absolutely abhor them.Do you mean type identifiers ($&# etc..)? If so I avoid those too. I exclusively use AS.