Advice on structure of VB Code

[alsaf]

I am working on an Access Database project which, at the present time, is mostly form driven with a little VB code. I have tried to make the VB code more understandable by moving as much of it out of the form modules to separate modules i.e. dealing with recordsets. I have some code in the form modules which does some validation and updates the current record field with information if a check-box is ticked. Would it be a good idea to put the code for this into a separate module as well or is that going OTT?

Another question I would like to ask is that due to the size of code is small, should I use classes?

[orange]

Why does moving code out of form modules make it more understandable?

What is the application? It's difficult for any of us to give advice when you haven't provided any context of you application.

Do you have a data model?
Do you have a set of business rules guiding your development?

[alsaf]

I hope you have had a good time over the festive period.

Please bear with me as many moons ago, I had done a software engineering course and since then some of the stuff I had learned there had given me a few bad programming habits. A few of these bad habits was never to use the goto statement and the flow of a function/procedure should always end with the last statement. The result of this was code I had written was more complicated than it should be.

Another sort of bad habit I picked up, which relates to the question I had originally posted, is that I was taught that each function/procedure should only do one thing. There has been times where I have looked at some of code I had written and I felt that at times it is badly written when making functions/procedures as small as I could. The advice I was asking is how far do you take that? For example, should the form module only contain code that relates to the form and code for data validation or recordset operations in separate modules? I'm not sure if this can be answered but I was wondering what balance do you take in order to make it on one hand understandable but not too over-complicated with functions/procedures calling multiple user defined functions/procedures?

As to my query about classes, please ignore as thinking about it, I have answered my question. The project I am working on is the administration of roles that employees in my company has to various systems. While, initially the database will perform just that, in future I intend to add more functionality that will automate the manual processes involved in this role administration so using classes will be a better option.