Programmer's Notes

[Cindy Ellis]

When I'm going to do something rather large or complicated, I tend to create a simple outline (usually in Word), then copy that into VBA editor (commented out of course) once I can see some sort of logical path from beginning to end. Then, when I start to actually go to work on it, I fill in the code in between the lines of the outline. It acts as more of a road map than anything else so I don't lose my place or forget something, but also makes it possible for someone else to figure out at least what I intended to accomplish in a section of code.
In the past 12 years, I've only developed 6 or 7 projects that I knew going in would be that complicated, but since I'm the one maintaining them, it's really for my own benefit to capture at least a bit of what the code is supposed to do.

 

[Sandeep Warrier]

I usually stare at the worksheet(s) I plan to be working on, while trying to come up with a logical workflow.

I also randomly flip between the worksheet(s) and the VBE till I'm ready to code something.

If it's something really complicated, then perhaps some steps of what I hope to achieve in notepad.

 

[schielrn]

I usually don't do any pre-planning (ok I never do any pre-planning). I get the scope of what someone wants and go with it the old trial and error way mainly. I do a lot of commenting and I will typically comment a line before I actually code it, so it is like I am pseudo coding, but am doing it on the fly instead of ahead of time.

Its always how I have done best. I have learned a lot from the trial and error method and probably doesn't really take me much longer than doing pre-planning and drawing it out.

With many of the applications I am coding on, nothing is, so called normal or in the same place all the time when I am grabbing data, so this method works best because whereever it fails I know I need to add logic or an if statement to check for certain things.

I also have at least 50-100 text files of different code snippets that I can throw into any program and adapt them. They are nicely named all in the same folder. This has been really useful and saves me a lot of time. I also have a folder for whole modules and userforms as stated before.

 

[Rasm]

For me writting the GUI first really helps - I use userforms - it is much better than flow charts I think. When you have the user interface - then the modules are much easier to define

 

[diddi]

@Rasm
I agree with your GUI method too. prolly should have said that in my blurb.

 

[chuckchuckit]

My programs usually involve processing large amounts of data that is constantly changing each minute, or sometimes by the second. I try to standardize my coding to process such, but as coding evolves it seems to require different ways to do/test things. Most require a lot of "if's" looking for potential situations, with code that may branch out from there like a tree.

So I always start with a piece of paper numbering what I think will be the needed order things should be done. Drawing boxes and arrows etc. Simplifying the big picture first visually on paper.

Then start VBA coding that larger flow for a very simple basic start to finish end flow. But leaving behind numerous crumbs of notes in VBA that say this and that need yet to be done. Later modularizing each crumb branch in separate workbooks and then pasted in.

I sometimes have more comment lines than code lines because once the best logic flow is figured out that proves to work, I would rather not have to figure it out again when modifying any options later. Sometimes my variables names are rather lengthy so their use is obvious.

Not always school textbook code. But I try to do whatever will make it "easier for me later", to quickly look at the code (and those green notes) to recall the reasoning and potential environment flow that was originally taken into account.

I kind of have a rule for myself that goes like: "If you are finished with this logic section and it took a lot of effort to figure out the right coding answer, now is the best time to leave comments about the reasoning and flow for that answer".

 

[chuckchuckit]

schielrn (or anyone else) -

I like your comment: "I also have at least 50-100 text files of different code snippets that I can throw into any program and adapt them."

Was wondering what storage editor/program you use? I am starting to program again past 6-8 months after programming in 'C' decades ago (Carpel Tunnel Survivor). I had a nice library then but 'C' doesn't apply in VBA.

Starting to build one again but I am storing them in a VBA file. But bit hard to find them. Tried MS Word but the spacing and tabs sometimes cause trouble.

Thanks. - Chuck

 

[shg]

I keep families of routines as bas files in an ad hoc VBA library directory. File names all start with a category: cht (charting stuff), comb (combinational stuff), file (file I/O), math, sort, str (string functions), xl (stuff that is intrinsically related to the way Excel works, like names, color indices, ...) followed by a terse description. I've done it for a few years, and I can usually find what I'm looking for quickly.

I edit them in Excel, but have Explorer configured to open then in NotePad++.

 

[chuckchuckit]

shg4421 - In your "ad hoc VBA library directory", what is the actual program you would open to save a new file there. Where are the stored?

Thanks.

 

[shg]

You can right-click in the Project Explorer window to export or import a module. Or drag a module between a file browser window and the Project Explorer window.