eHome Digial Tools

First off, this isn't an important topic, it's very low-key. I don't really use eHome yet, but I do think about scripting a lot. These are just some suggestions to make it more accessible to users.

I don't like the way they are named and look. It seems so archaic to edit the scripts. Though I don't do that either, I'm just saying. Have you considered using more descriptive english-ish names? Let's take this as an example.

Code: Select all

g_oGbl.EH_Shell2File g_oGbl.p_sApplicationPath & "eHomeBrowser.exe http://www.yahoo.com"

Here we have variable names using scope, name abreviations, and type identifiers. As programming has evolved over the last few decades so have the generalized standards around programming and syntax.

First, it's generally not accepted anymore to have type identifiers on the name. The names should be descriptive enough to imply what type they are.

Second, scope identifiers genearlly aren't used on things that are public. Why? Because they are public and if I can access it from the outside, it does me no good to see g_ or p_ because I should never see m_. G_ isn't really used either because G_ just means it's available everywhere. You should just be using a grouping name for these. The Gbl name signifies Global stuff, which is all misc categorized. The scripting engine (when you call AddObject) allows you to specify that all the members of the object can be added locally to the script, not requiring any prefix variable to access them. Essentially

Code: Select all

oGbl.EH_Shell2File

becomes

Code: Select all

EH_Shell2File

Third, the EH prefix (which means eHome) probably is visual overkill. This should be removed or broken out to sub level objects. Your global object can have a property which references a class that contains the stuff grouped together of EH, like so:

Code: Select all

EHome.ShellToFile(blah...)

Of course you may do some sort of parsing of the script code to find all functions declared with EH_ while that works, and is handy for you to figure out what is defined, we've done it a different way in the past. We more or less had an event registration system which provided an object model the script would access and register local methods with defined events declared in the framework. This let us easily track, audit, debug the "setup" code for the script and figure out any issues in advance.

Taking the original example, let's see what it would look like if it was "cleaned" up so to speak:

Code: Select all

eHome.ShellToFile CurrentApplicationPath & "eHomeBrowser.exe http://www.yahoo.com"

Much nicer to read

Thoughts?

I'd buy that for a dollar!