Names
This is against 'best practice' but if you keep it to a minimum for the most frequently used elements in your applications, then it will increase your programming speed and debug time.
Module Names:
AG - Application General - Global variables and subroutines that are standardised across all of my projects.
AE - Application Errors = An error management module that takes input from subroutines and the error class and creates a form to assist with diagnosis.
AV - Application Variables = Any global variable that is specific to this Application.
Note# Modules load alphabetically in Gambas, so if must you have dependcies between them, keep that in mind.
Toolbox Class identifiers:
DT - Data Tables - This is a list of all data tables used in the database for the application.
TB - *sigh* Initially it was a toolbox of subroutines to manage database IO and I should have changed the name but now I'm sort of attached to it from a historical perspective. It was the first toolbox class that I created in Gambas.
DBC - Database connection
Why 2-3 letters?
Take the Data tables example.
The class contains a variable for each table that I use in my database.
Public Const TableName as String = "TableName"
I declare the DT class in the AG Module
Public DT as new Class Cls_SQL_ DataTables so I can reference any table in my data base as AG.DT.TableName
I NEVER refer to a table identifier by other than this standard. It minimises errors and alows you to change the table name once and you don't have to rewrite the code across your applicaiton.
I reference table names constantly. So it comes down to using ApplicationGeneral.DataTables.TableName OR AG.DT.TableName.
The reason why I do this abrieviation is that I want to be able to see as much of the calling subroutine code as I can without having to scroll the screen. It makes error diagnosis faster and easier.
This is an actual use case to demonstrait loading a combo box with records from a table.
In the toolbox class (TB) it is delared as Public Sub LoadComboBox(InTable As String, InField As String, InCriteria As String, OrderBy As String, InCombo As ComboBox, Clear As Boolean, Title As String)
TB.LoadComboBox(AG.DT.Category, "CategoryName", "ParentId=0", "", Cmb_CategoryParent, True, "* Select Parent *")


Comments
I like reading other's coding styles as I usually find it improves how I do things.
I'm looking forward to reading more of your blogs, Quin.
I've been planning to write up a few things and a blog is much better suited for this than the general forum subject areas.
Over the years, I've written a 'sort of template' to make it easier to create new, more complex programs. As stated in my Bio, I'm more about the practical use of Gambas now than experimentation.
I still do the occasional Q&D (Quick & Dirty) code when I want to test something but generally, I can throw together a reasonably complex app in about an hour or two.
I'll keep writing them up until I run out of subject matter…er…which may take a while
I'm still working on the GPRU ( Gambas Project Review Utility ) which I'm using more and more. Still have a few bugs to track down, for the automatic documentation and help page templates, but it should be ready to post to the 'Project Showcase' once I've had it tested by a few others.
I also have Story Lathe, which is an application to manage writing a manuscript. I've been writing an epic fantasy novel over the last 4 years and developing the application as part of that journey. It's been a rather fun time.
I'll be interested in seeing what others think of my …programming style. It may be a bit 'old school' now but I'm not that 'get off my lawn' old that, I'm not open to new ideas.
His blog was up for 3 days before I noticed it. I'm working on changing how blogs are "announced".
Curious at what more to come…
Always interested in how others manage their code…