The OpenEdge Hive

I'm reading Martin Fowler's refactoring and will work out some of his methods (which also apply to building new software) in this blog. Read this to get some background info:

http://sourcemaking.com/refactoring/introduce-parameter-object
http://www.refactoring.com/catalog/introduceParameterObject.html
http://martinfowler.com/ap2/range.html

Below a simple daterangeparameter object, and therebelow a procedure using the daterange object.

It has been noted that once something is on the internet, it is there forever. Apparently, this is somewhat wrong for certain types of information. The Progress E-Zine collection continues to be available on the internet, but often it is tucked away in corners that are hard to find.

With this in mind, a three volume set of the E-Zines in bound printed form are now available. No more binders full of printer paper versions of the monographs, simply reach into the book shelf for the bound copy and enjoy.

The books can be purchased from these locations:

http://www.lulu.com/content/paperback-book/progress-e-zine-collection-vo...

http://www.lulu.com/content/paperback-book/progress-e-zine-collection-vo...

http://www.lulu.com/content/paperback-book/progress-e-zine-collection-vo...

In the SaaS world, often customers will want their own customizations into the source code specific to how they want to do business with your software.

Here is a point where object oriented programming stands out. By crafting your programming in such a way that basic functionality is enhanced - you can use different classes specific to particular customers for enhanced implementation.

Since we are going to potentially be using one of multiple classes, we need to have an interface describing the methods available in the class.

One of the important things in software development is to do unit testing - that is a set of tests the programmer can do on a piece of code to be assured it is most likely working the way one wants it to.

Surprisingly it is rare to find unit test code as part of a source code file. If it is created at all (horror), it is usually tucked away on some developers disk someplace or simply thrown away!

What I have found helpful for myself as well as others working the same code, is to place a comment at the end of the program with the unit test code.

I am working on a manual of code standards for my division, and would appreciate input about this. I've incorporated (or adapted) many of the entries from the prolint lists of bugs, style improvement, performance enhancements, etc. Of course this will be a combination of helpful advice, common sense, ways to make the code more readable and re-usable, and ways to prevent problems down the line.

I will appreciate any suggestions or ideas that are sent in.