# Programmer's Notes



## MrKowz (Mar 1, 2011)

We haven't had a random discussion thread in a bit, so here goes!

Do you jot down anything or have any particular procedures you follow when programming something out of the norm?  Sure, a lot of us can throw out macros that have a loop and some basic logic off the top of our head, but what about when you have a really complex task?

I find myself sometimes drawing a small flowchart for the loops that have many different paths.  Or sometimes, if I'm trying to write a formula that I know is going to be big/complex, I'll write out in words what I am trying to do (putting space between each line) and then try to translate it into crude Excel language.  But for the most part, I just start writing code, and read/re-read/correct it as I go.


----------



## RobMatthews (Mar 1, 2011)

Arrgh. Just lost ten minutes worth of typing due to bumping the "back" button on my mouse. And forward didn't bring it back. Oh well. 

Short story- grade 9 or 10 teacher told us to flowchart, then pseudo-code, then code.
I tend just to code, sometimes doing pseudo-code prior to a complex task, and flowcharting for the real difficult stuff.
I don't comment enough, but i do use meaningful variable names.

Edit:
@ruin3r: Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live


----------



## Taul (Mar 1, 2011)

Generally I just write the code. It’s only when I get stuck, I go back and either write it in words or scribble out some crude flow chart. But most of the stuff I do is simple enough to code straight away.

I do annotate all my code; mainly because I have a poor memory, and if someone asks me to change something, I rely on the annotated notes to save me the pain of learning it all again.

I have spoken to professional coders (well contract guys anyway) who keep their library of code annotated, but remove the annotated notes before publication. They take the view that it took ages to learn and they are not giving it all away for nothing.
I can’t blame them really, they have to protect their income.


----------



## sous2817 (Mar 1, 2011)

I always start off with the intention of "planning, pseudo-code, more planning, well-commented code".  

The reality is...deadline is too short to do anything other than sit down and chug away.  I have been better about commenting though.  The amount of times I've come back to something a few months later and said "Why the flip did I do it like that, this way I just learned is way more efficient". Proceed to make a ton of undocumented changes, rerun code and the realize "oh...so THAT'S why I did it that way!"

One of these days I'll be able to talk my manager(s) in to the benefits of planning and design sessions before getting started.


----------



## SydneyGeek (Mar 1, 2011)

I try to make it as modular as possible, for big routines.
Get a chunk to work, then go to the next (often a separate Sub). It's easy to daisy-chain the calls when you want to run the whole thing.

For each routine, if it's got more than one or two logic steps, I create comments before I code, then write each section.

As for removing comments before going live; I'd shoot myself in the foot if I did that, given that I usually maintain the code anyway. 

Denis


----------



## VoG (Mar 2, 2011)

Plan and document code? Bizarre


----------



## TinaP (Mar 2, 2011)

Mostly, I just sit down and code, but I pseudo-code and flowchart the more complicated stuff just to make sure I know what I want to do. Modular coding helps by breaking down the task to small steps.

As far as commenting, I used to code with very few comments, but like the earlier commenters, I couldn't troubleshoot the code. On two recent occasions, I had to totally rewrite the code for two macros. One was an uncommented mess with nested ifs six deep in spots. When I tried to fix it, I ended up with non-functional code and three hours of my life that I'd never get back. The new code is fully commented. Lesson learned.


----------



## JazzSP8 (Mar 2, 2011)

If its something out of the ordinary I tend to the write the code in Pseudo-Code mixed with real code in Notepad before copying it into the VBE; that way it sort of builds itself in my head as I write round it, not the normal approach I know but it tends to work for me...

As far as commenting goes - Then, same as above - When I was first 'taught' about commenting I more or less ignored it until *that* time comes when you need to go back to something you've done a year or so ago and you don't have a clue what you've done, like most above all my code is now commented and commented well.

(I like to think that I was a much cleverer man in those times as I don't understand it anymore, somewhere inside me knows that this isn't the case though...)

Weird thing is, I love flow charts for anything apart from programming .. Give me a copy of Visio and I'll flow chart anything apart from a computer programme...


----------



## Jon von der Heyden (Mar 2, 2011)

Obviously depends on the project, but using classes tends to help me compartmentalise the different elements.  I tend to think what objects I need, what properties and what methods.  Then I go from there...


----------



## diddi (Mar 2, 2011)

the @SydneyGeek method is a carbon copy for me.  perhaps its the .au teaching methods from the era.  i started on Fortran back in the days of marksense cards and went through the non-visual stage of 20kLOC abominations, all subbed out to run on low RAM systems.

the other thing i do is keep a library of solid code fragments that i recycle over and over. and recently i have started collecting entire userforms that i can plonk into new projects which i have found really helpful.


----------



## Cindy Ellis (Mar 2, 2011)

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 (Mar 3, 2011)

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 (Mar 3, 2011)

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 (Mar 9, 2011)

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 (Mar 9, 2011)

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


----------



## chuckchuckit (Mar 11, 2011)

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 (Mar 11, 2011)

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 (Mar 11, 2011)

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 (Mar 11, 2011)

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 (Mar 11, 2011)

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.


----------



## chuckchuckit (Mar 11, 2011)

I'm not quite seeing it yet. If you had following code you wanted to save that is in Sheet1 VBA editor for currently open workbook, how would you go about saving it to a file with a name of "Ranges01"


```
Sub RangeExample()
    Range("A1").Select
End Sub
```


----------



## shg (Mar 11, 2011)

In the Project Explorer window, you can see a list of modules in the VBA project. Grab any module with your mouse and drag it to the desktop, or to any open file browser window.


----------



## chuckchuckit (Mar 11, 2011)

I see. That might be an easier way to move code around if they are in specific files or functions ready to go. Using a .bas format. I'll play around with it some.

Thanks.


----------



## Rasm (Mar 11, 2011)

use something like this - you can set your CurrentPath to what you want - also change the file name to wat you wnat


```
Dim NewBookX As Workbook
Set NewBookX = Workbooks.Add
 
 On Error Resume Next
    NewBookX.SaveAs Filename:=CurrentPath & "\" & "WhateverNameYouWant.xlsx"
    If Err.Number <> 0 Then
        ActiveWorkbook.Close    ' closes the active workbook and lets the user decide if changes are to be saved or not
    Else
        ActiveWorkbook.Close False    ' closes the active workbook without saving any changes
       'ActiveWorkbook.Close True    ' closes the active workbook and saves any changes
    End If
```


----------



## Rasm (Mar 11, 2011)

ohhh insert a 

err.Clear 

after the 'on error resume next' - just in case


----------



## schielrn (Mar 11, 2011)

chuckchuckit said:


> 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."


I basically have all of mine stored on our network drive at work and also on my flash drive.

They are in a common folder on the netword drive that anyone can access and people go there to pull different things.

I try to have dscriptive names of the files, like I have for instance:

SeparateTabsbyAutoFilter.txt
SeparateTabsbyArray.txt
SeparateTabsbyArrayFasterVersion.txt
SeparateTabsbyArrayMuchFasterVersion.txt

They do the same thing just in a little different way. And I can probably delete some of the slower ones . But inside of each text file I have built a comment section at the top that goes more into detail of what this particular program actually does.

Then they can just open the text file and drop it into a standard module.

If it is a procedure that might need other functions/subs like getdirectory() I have included those in those text files.

I do have some exported whole modules and userforms as well within there.

Hope that helps explain how I do it at least.


----------



## SydneyGeek (Mar 12, 2011)

I build small working samples of workbooks / databases, then show them in a resource directory.

When I get around to it I write stuff for my website -- instant access  but the trick is to remember to update when I come across a new tip / technique.

Denis


----------



## chuckchuckit (Mar 12, 2011)

schielrn - I like the idea of your directory being .txt files. So easy to carry around (flash drives etc) and others can use them too.

Wondering what .txt editor you are using? To actually create the exported code? Am assuming then you just copy and paste from opened .txt files instead of import?

I am starting to collect and write a lot of code that I need to organize better. Still trying to decide which route to go.

Thanks.

Chuck


----------



## SydneyGeek (Mar 12, 2011)

I came across this; freeware, with a version that you can load onto a flash drive. 
http://www.garybeene.com/gbware/gbcodelib.htm

If you do more than VBA (say, PHP or VB.Net) you can have that in the library too, and search by keyword. 

Denis


----------



## shg (Mar 12, 2011)

> I like the idea of your directory being .txt files


.bas files -- what you export a module as -- _are_ text files.


----------

