Clean Code

[GBalcom]

this post isn't to ask any specific question, but rather to discuss what you do to try to improve your code and your code writing. Mods please move it if necessary to whatever forum is most appropriate.

I just finished reading the Kindle sample of the book "clean code". I, like most VBA users, am not a full-time programmer. I started off (and still am) a "Power user" who has grown some in VBA and programming after 5 or so years of beating my head against the wall. I read this forum, have read some good books on Access VBA, and follow most things FMS and Rubberduck put out.

I feel that for self-taught (no formal computer science, programming etc.) I'm not half bad. But I'm always pushing myself to improve. In the last two years, any new code I've written has tried to keep business logic out of forms and in class modules. I try to break methods into smaller chunks (single responsibility), and I've even begun using interfaces when appropriate.

There are some simple things I haven't tried yet-- things like passing recordsets in method arguments or creating a wrapper for a recordset. I would like to try this if and when it makes sense.



After my long winded intro, I'm curious what others are doing to improve the code they work in...What are you doing today, that you weren't doing in years past? What makes your code easier to read and maintain now?

 

[NauticalGent]

Hi GBalcom,

I feel like you have taken a page from my memoirs, except you seem to have done a little more than I have.

Personally, once I grasped the concept of passing arguments to UDFs and Procedures, my code has gotten much more cleaner and efficient. I am sure if some of the Heavy Weights on AWF were to have a go at it they would find some areas for improvement but I am somewhat pleased with my development and progress - mostly as a direct benefit from this forum.

Not going to run this into the ground but I will share one example. The developer who built the application I inherited was a COBOL programmer who had to learn Access as a collateral duty to his main job. One sub, which was part of a bound form, was over 1300 lines of code and the vast majority was the same code with different parameters. Learning how to pass aurguments to Functions and Procedures, and using unbound forms have allowed me to reduce the main sub down to less than 250 lines of code.

It isn’t a perfect product yet because everytime I get something done, someone comes along and posts something that makes me think “Now WHY didn’t I think of that?”

One last parting shot. About two years ago I was having a bit of trouble getting some bit of code to work. It was JDraw who came along and introduced me to Debug.Print and how to use it to sort things out. It was quite the kick-start and it is amazing how one or two sentences from someone can change so much.

 

[The_Doc_Man]

GBalcom,

If you want to clean up your code, here are a few things to look for... in NO PARTICULAR ORDER so don't take this as a priority-ordered list. I'm shooting from the hip.

1. Modularize. You can put lots of code in general modules and can have more than one general module in a project. In my largest project, I had modules with code dedicated to Excel interactions, Word interactions, Outlook interactions, File System Object interactions, user/role security testing, a special text-parser module, a specialized statistics module, and a module for diddling with the appearance of form controls based on a state variable. Plus, of course, the module that had site-specific requirements that were not as general in purpose as the other stuff.

2. Maintain Isolation. Except in extremely rare circumstances, I was SCRUPULOUSLY careful to never reference anything that wasn't either locally defined inside the routine or a formal parameter. That is, I avoided use of global variables like the plague. Having said that, the exception was that I allowed the routines in the Excel module to reference Excel application objects in the Excel general module's declaration area - but NOT from anywhere else. Ditto, security-related objects in the security module. And so on and so forth.

The reason is that if you have a good set of tools, you can EXPORT the code into a text file and put it in your tool box. Then the next project comes along and you have a full tool box ready for work.

3. Consistency. Yes, I know... consistency is the hobgoblin of little minds. But the other half of that quote is "... but it is also the servant that faithfully serves the wise master." By consistently declaring variables where they are needed, in an organized and predictable way, you assist yourself down the line in debugging. By consistently defining status returns for subroutines, you make it possible to know where things went south on you. By consistently placing error traps in subroutines, you assure that you will know WHEN things went south.

4. Neatness. There are those who say "cleanliness is next to godliness." I don't know about that. However, I do know that if your code is neatly indented in such a way that the various code blocks stand out, you do yourself a favor down the road when you have to come back and look at the code while asking yourself, "What the HELL was I smoking when I wrote this code?"

5. Commentary. When I was a project manager, I told my people that I wanted to see comments in their code to capture what they were thinking in a particular design. I wanted to see notes in-line and on stand-alone lines as well. (It's a follow-up to the "what was I smoking?" question if nothing else.)

6. Focus. When writing functions or subroutines, shoot for atomicity. It is easier to write several small focused routines to each do a finite part of a process (and then write an overarching routine to call the focused parts). If you have a routine that does four or five things before it finishes, you have to ask yourself "What does this block of code do again?" Comments help, but isolating functions to minimize the complexity of each part is just good programming. BECAUSE if you isolate the functionality, the parts are FAR easier to debug as single discrete steps.

Trust me, if you write a 1500-line routine, you will learn to regret it because it will be hard for your mind to focus on such a thing as a gestalt. I'm not going to put an absolute limit on code size, but if it takes you more than a couple of printed pages for anything but the highest-level routine that calls all the other stuff, then you did yourself massive dirt.

That was six shots from the hip, I'm empty now. But maybe I hit a target or two.

 

[Cronk]

And if Doc gave me permission to add to his list, I'd add
7. Always name any control that you make reference to in code, with a name that indicates what it's about. Same with defined variables
Rather than

Me.Text67=X

much better

Me.txtSurname = strSurname

It makes it easier for anyone else looking at your code, or indeed yourself if you come back to it after some time.

 

[Pat Hartman]

I guess my COBOL was more organized than your predecessors. My hardest problem with Access was understanding the event model. But once I got the hang of it, I loved the fact that Access took the tedium out of development. My suggestion is that code should be your last option. Use property settings, conditional formatting, and queries to do as much of the work for you as you can, then write code. And always be on the lookout for potential future usefulness. Sometimes I write code in a hurry and find out later that I actually need to use it in multiple places. So, I bite the bullet then and pull it out into a procedure or function. Frequently I pass in a form reference and because I a pretty consistent in how things are named, the code works in lots of places.

In addition to what the others have suggested, I find consistency to be important. If you have a database about employees, don't call them EmployeeXXXX in some places and EmpXXXX or EmplXXXX in others. I find as i get older and work on more applications, I have less room in my brain to remember column names from all my active applications so it is less frustrating to me if I have to pop in to do something in an app I haven't touched in a while if I don't have to constantly look up column and other object names.