[Gambas-user] Best Programming Practice

Tobias Boege taboege at ...626...
Mon May 12 16:54:21 CEST 2014


On Mon, 12 May 2014, Tobias Boege wrote:
> On Mon, 12 May 2014, Nigel Verity wrote:
> > I think that the issue of best programming practice and how many forms are used to accomplish a task are two separate issues.
> > 
> > Sharing common code between forms, rather than having multiple instances of procedures and functions, is always good practice as it makes maintenance and fault-finding much simpler.
> > 
> > How you divide a task across forms depends largely upon the workflow. However, there are some factors which really just boil down to the preferences of the users. Some people like to select records for maintenance from within the maintenance form itself, while others prefer to select data from a separate popup. You may not be able to please everybody in your UI design decisions, but you should seek to satisfy the majority of users.
> > 
> > The tab order of fields can be important. For example highly repetitive tasks, such as entering client information, will often be performed without the experienced user actually looking at the screen; just using the tab key to move between fields. If the tab order doesn't follow the way users naturally work this can only lead to problems, even if their preferred order may seem illogical to you as the developer.
> > 
> > In my experience, if your application is only going to have a very small number of users then you can probably educate them to accept a user interface (both the layout and the way you decompose the task into forms) which is both logical and easy for you to maintain. On the other hand, if you have a large number of non-technical users you would be better advised to give them what they say they want, within the constraints of the application's functional requirements, and just make sure that you apply best coding practice and any other approaches to development which make the maintenance as easy as possible.
> > 
> > If you decompose a task into multiple forms consider very carefully the use of the form's "modal" property. If formA spawns formB non-modally, and there are dependencies between them in both directions, the coding required to keep both in sync can become very complex. However, if formB is modal then you only have to refresh the data on formA when you save and/or close formB. It makes life somewhat simpler.
> > 
> > One more thing......
> > 
> > Document the application well, making sure that you highlight the reasons behind any process flow or task decomposition which you would have implemented differently given a completely free choice. Otherwise, subsequent developers may just assume that you are not a very good programmer and implement "improvements" which only serve to upset the the users.
> > 
> 
> Are you criticising any of the programs distributed with Gambas? If so,
> please say explicitly which one so we can fix it.
> 
> If not - and there is also no question subtly between the lines which I
> missed - I'd say that this text rather belongs on your blog or something.
> 
> Don't get me wrong: I have no problem with people plainly sharing thoughts
> (even without demanding any reaction from others which makes the whole
> situation a little awkward - because, you know, it's not productive) but
> it is uncommon on this mailing list. And before you are left alone with a
> question I could not extract from your mail, I thought I better ask back :-)
> 

Oh! I'm sorry.

I missed that this mail was an answer to another mail. I guess those things
happen when a thread is for some reason broken up in your mail client and
you work "newest threads first" :-)

Sorry for the noise!

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk




More information about the User mailing list