Welcome to Quin&#039;s Corner

Hello, Guest!
Many of the questions I've seen raised on the forum are not so much about specific Gambas issues; but more around coding in general and some of the bugs in submitters entries have been introduced by less than optimal structure in their written code.

These articles will contain information on how to plan, structure and write application code that is robust and easy to maintain in the long term.

Guest, if you have questions, just start a post on the Ask Quin forum and I'll be more than happy to answer general questions on how to structure your code and will write replies in the newsletter for some of the common questions.

Special note to "Newbies". We were ALL Newbies once, and my philosophy is that:"there is no such thing as a dumb question", so don't feel that you are alone in your quest to learn how to do things. Ask ! It's the best way to learn.

Design Principles - Before you sit at the keyboard !

Quincunxian in the usergroup ‘CEDI Editor’

Quincunxian in the usergroup ‘Community Saint’

Greetings all,

I'm currently helping Conrad, an enthusiastic but self confessed Newbie to Gambas, to work on an exciting project to do with Home Automation.
While Conrad's requirement is around some rather large scale water irrigation for his property, the same design principles and problems apply to
anyone who is thinking about starting a medium to large project.

I'll keep everyone informed about how this specific project progresses as I'm sure that there are a lot of members who would like to do some work with
Gambas and automation control - It's a learning journey for me as well so I'll post up in general forum as things come to hand.

Scoping document.
All large formal projects start with a scoping document.
This outlines what you expect to achieve with your project and lists the 'objectives'.
It can list data sources, table fields, what screen displays look like, the number of forms, any special classes that you have to write….
This does not have to be a "War & Peace" document, just a single page will sometimes do; but it is good to refer back to
so that you don't suffer from what is know as 'Scope Creep'.
Some block diagrams with a few notes in a notepad is all it needs to be; but what you need to do is stick to the outcome !
Often, as you start to write things down, you have that "Mmmmm how the hell am I going to make that work" moment.
This can save you a lot of wasted time and while this appears obvious when written down, you would be surprised how many professionals
fail to do this well.

The Evil of 'Scope Creep'
I must admit that I'm not immune to this horrible beast and I have to keep reminding myself that I need to keep the original goal in mind and not add
'Oh that's so cool, I'll just add that as another feature', again and again and again……
Scope Creep = never really finishing a project and it gets so out of hand that you end up giving up on what was originally a great idea.
The other important thing to note, is if you are writing a program for someone else, this scoping document ensures that they don't keep
adding features to the work in progress (WIP) and you end up with the "Never Ending Project"
(Please note that Conrad's not doing this , but it was a good common issue worth mentioning.)

Version X
As part of your scoping document, you can include a page for 'Version X' notes.
You can quickly jot down the great ideas you have as you are writing the code for your application in a list for the NEXT version
and then when the times comes to being work, you already have a good idea of what the NEW Scope is, how it relates to the code that you
have already created and this will help you to ensure that you don't end up with 'Spaghetti Code' See Spaghetti_codeon Wikipedia
Please read this short description of code types, as it covers some very interesting points.

Cheers,
Quin