How do you develop your code?

[sarver311]

Hey Everyone,

I think the greatest perk about using macro scheduler is you don't have to be a programmer to develop applications with it. However since I am not a programmer I also don't have a background in the actual Development and maintenance of code which is almost as important as writing the code itself if you ask me.

That being said I thought it might be insightful to see what methods or resources some of you guys utilize in your process from idea to finished product.

I realize these posts could get ridiculously in depth but little hints, tips and strategies go a long way. To start it off I thought I would share my process.

Ideas
First thing I will do is obviously come up with the need for code. If it is going to be a huge project I will open a Google doc where I list my immediate goals and what I want to accomplish. After that I break the outline into smaller sections like interface, code, subroutines, database etc. Other times i might just break out the old fashioned notepad and pencil and do some brainstorming diagrams to help flesh out the ideas and the processes.

Coding
For coding I have found it really helpful if I do pseudo code when scripts are in the infant stages for example.

start script
load variables
pull Combobox lists from database or ini
declare dialog(s)
declare event handlers
start action loop
show dialog
declare the subs

Obviously this is a gross oversimplification and it is usually in much greater detail but it has really helped me stay on track to outline my more complicated projects this way. It helps me get my overall picture then flesh the individual sections out and when I'm read I just convert the pseudocode into my actual code (just remember to comment out that Pseudcode!) For simpler projects or areas of the code I'm really famliar with the commands etc. I tend to skip the pseudo coding step.

Once I've made the code I have found it eternally helpful to name my scripts with version numbers. I will keep a group in my mscheduler screen that I call "old scripts" so once I have an older revision I just toss it in there if I ever need to reference it. Then when I'm developing a new revision, before I put it into "official use I will have the same script with two file names. So an example of the naming convention would be I'd have one called sdhelper v2-5 and sdhelper v2-5-testing. So I make my improvements in the testing script and once that seems stable I copy it over to my regular 2-5 version. The nice thing about this is if I pork my testing script I can just copy all the code from the 2-5 script and start over. Once I have made decent headway with it I will eventually start a 2-6 version and begin mapping out my plans for the next new bug fixes or improvements.

New version Planning.
I like to have one big document where all my versions are listed. Whenever I am planning my next revision I just add to the beginning of the doc my revision name and then the following four categories

Sdhelper rev 2-6 release information

Pending bugs

Pending improvements/Features

Fixed Bugs

New Improvements and features


At this point I populate the first two sections with all the bugs I would like to fix and and improvements I'd like to include and then as I go down the line I simple cut and past the bug from the pending category to the fixed category. The same for the improvements section. This helps me stay organized and keep track of what I'm fixing/has been fixed.


Other Resources
Some other resources I really like are the following

Books
Code Complete by Steve Mcconnell has a lot of great dos and don'ts for programming

Database Design for mere mortals - If you wanna learn how to make a great database this book breaks it down Extremely well!

Websites:
Google is your friend!
MJTNET forum goes without saying but I'll say it anyways. =)

Tools
Google docs (any word program is great but I love being able to access my docs and share them from anywhere)


So that is about it, I hope it didn't seem overly simplistic or redundant. I am no pro but this is the process I have developed over the past few years of working with MS scheduler. I have found that so much focus seems to be on the end result of making a script yet the actual element of developing and maintaining them is often overlooked.

I hope you guys enjoyed it and possibly got something out of it. I am really interested to hear what you guys think and what you do for your process.

-Josh

[idiot]

I prefer an easier method for making scripts. Macro scheduler reads 1 line at a time so a top down method seems easiest. What you want it to do first then second third etc. . First write code for what you initially want it to do. Your first task then debug and do a test run. then write 2nd task etc.. Adding each piece you need for script 1 section at a time. My work is sloppy and i spend a huge amount of time fixing typos. If your a begginer i would focus on 1 command at a time to do what the task is you need done. So you can learn how they work and can incorporate more and more commands as you go along.
Then learn how to make functions and more technical things. You need a solid base understanding of the commands before you get to advanced. Once your really good you can start learning pipeing. Wich is used to get macro scheduler to do more then 1 thing at a time. It will only read 1 line at a time, but can do many actions at a time.
If you get a good grasp on pipeing. I learned simple pipe-ing to make an auto typer using vk codes. Now i incorporate it in many more areas such as image recognition to find multple images at a time, things like that. The team here is very knowledgeable and helps everyone very much and the program is outstanding.
Ohh and even if you understand pieing. You have to be careful of memory usage it can spikeway to high and cause issues. If you try to do to much on your machine. So when ever doing multiple things at once while it can be effiecient can slow overall performance if your not careful.

[Marcus Tettmar]

Idiot,

I don't wish to be rude, but would you please consider writing with punctuation. It is very hard to read your posts.

http://en.wikipedia.org/wiki/Punctuation

[jj45410]

Idiot,

I don't wish to be rude, but would you please consider writing with punctuation. It is very hard to read your posts.

http://en.wikipedia.org/wiki/Punctuation

At first I thought you were calling him an idiot, I thought "Thats unlike metettmar" but then I realized it was his name. haha