It is true that some older languages required functions and
subroutines to be defined before use. In this thread, though, that's
bbeing called "top-down design." I remember "top down" meaning the
opposite: main before subs, big plan before details.
It's also true that people will have different preferences, so for
what it's worth, here are some of mine :-) :
Top down, meaning big before small, so that a new code reader can get
the big picture before having to worry about exactly how smaller steps
are done.
Variables defined only when and where needed, so a new code reader
need not wonder, on line 425, why "x3" is defined and only find its
first reference on line 600 (ok, big function there, but things happen :-) ).
Code split into segments, usually one segment per file, based on
purposes and subpurposes. Minimal linkage between segments, or
"modules," as I like to call them. This means, for example, as few
shared global variables as possible. The idea here is to make clear
what one module needs with another and reduce dependencies between
them that might be hard to spot.
As far as the point about thinking a function or subroutine call is a
new script language feature, I resolve this possibility with text
searches, which admittedly are more possible and powerful than they
once were.
As for my own history, I started programming in 1983 in BASIC and 6502
machine code for Apples, which means my programs looked on paper like
any of the following:
10 rem Print the banner
20 gosub 900
30 rem Set up files
40 gosub 2000
...
or
0300 20 80 03 JSR $0380
0303 A9 01 LDA #$01
0305 20 A5 03 JSR $03A5
Or just...
0300- 20 80 03 a9 01 20 A5 03 ...
>From which, I'm sure all would agree, we've come a long way. :)
On Tue, Apr 19, 2011 at 08:56:21AM +0200, David wrote:
Guess, one reason why many people will do their definitions - including
their subrotuines and functions - at the beginning, then do the main
body of the app; it all comes from old. At least, for the ones of us,
who is coming in from the old days, we are all used to things like
Pascal (and I do believe it was the same thing in C). In those
programming languages, you were not allowed to do anything, unless you
first had the Variables, Procedures and functions, already defined.
That meant - since the encoder would process the program (app)
consequtively, starting out with line 1, and finishing with the last
line - you would have no other choice but to place your main body at
the bottom. The transformation into scripting, is a bit of a jump over
for old-timers like me and many others. Specially so, when comes to
reading other peoples app code. You read, and all the sudden meet up
with an instruction, that looks intesting and nice. Right away, you
think this is a built-in feature of the scripting language, and so
implement the instruction in your own code. Then try to run your newly
constructed app, and are left with an error thrown at you, and pretty
soon the waiste basket full of newly pulled hair - since you do?n't see
why that error got thrown at you. Finally, you decide to read the rest
of the 1000 lines from the original script that you downloaded, and at
line 995, you find the reason for being bald-headed: This was an
instruction, pointing to a subroutine of some kind, that the author has
put the code of, at the very end of his script. I have been playing
around with scripting in VBS for a couple of years now, and still find
it confusing to see main bodies at the top - or even somewhere hidden
in between all kinds of subs, functions and variable definitions. After
something like two decades of Pascal programming, it all looks to me,
as if you were going to do a job - like building a house - and you put
the hose on the plot first, then brought out your toolbox.
Another practice, that I don't find very convenient when reading
through other peoples code, is the tendency of scattering their
variable definitions (dim statments) all over the place. Again, looks
like a carpenter, who just left his hammer, saw, screw-driver, drill -
all over the plac - simply dropping it where he found it convenient.
Then atain, when in college, studying for my electronic edducation, we
were always told to first sit down and figure the problem find a
solution, make up our minds on what to do, where, when and how to do
it. This meant, to bring the tools we needed. Guess this made the basis
for our computer skills, as in the method of programming described
above (taken from Pascal), you'd have to define - or as if it was,
bring your tools - at the beginning of the code.
Again, think of a person who wants to bake a cake. She would typically
go to her cuppard and fridge, making sure she had what the reipe told
was neeeded for ingrediences, before she would even dream of getting
started with the baking process itself. Or, are you used to start
cooking, all the sudden realizing that you are out of eggs, then run to
the store and pick up eggs (or let's say put ind an instruction in your
code - Dim EGGS). Then coming back to your cooking, you continue with
the job, only to realize you now are left with the lack of a qurter of
milk. S, you drop down to the store and pick it up -. or in your code
Sub Quarter of milk() ... End Sub 'Quarter of milk.
For people who got started out directly in modern scripting, all of
this chatter of mine, might seem useless. But at least, that is where
old-timers like me are coming from. I am not going to claim that the
one way of handling things are to be more correct over the other.
Simply just letting people know, why some people tend to put the main
body here, others will drop it there. Good thing Windows doesn't mind!
Smile. After all, one practice that would have been helpful, but which
seems to often being left behind, is the clearly marking of where your
different parts are placed in the code. Good commenting habits, I
guess, is the keywords here. Again, here you will sometimes see that
there is a couple of practices. Some people like to do the job first -
writing ther line of code -and then explain what they have just
accomplished, by dropping a comment in their app code. Others, like
myself, find it more useful, first to tell the reader WHAT you are
going to do - then go ahead and do it. Like:
'We now will take an user input of the phone number:
PNumber = Input "Phone number please? "
Again, none of the methods are more correct than the other. And
different app authors will cling to the one or the other. But, as
people start to read the different app codes from others, they might
wonder why all this differences in practice - and does it matter what
way I personally handle the job. In things like VBS, and in the cases
here discussed, it doesn't matter for the performance of the app. But
it might impact the readability of the code, mainly for yourself. So,
at the end, I think it will stand as this: Find the practice that you
yourself are familiar with, then go ahead. Only, keep in mind that
others might want to read your app, or you yourself want to modify it
at a later time. That's why, it is always good to make sure, that it
stands out clearly what you have done. A small 'log-file', that goes
with your app, is of course a pretty good idea. Yet, see how many does
keep such a logfile? Smile!
----- Original Message -----
From: [1]Chip Orange
To: [2][email protected]
Sent: Tuesday, April 19, 2011 3:33 AM
Subject: RE: VBScript NotePad App and Loading To App Central
Very nice Rick; thanks, and I hope everyone in the class will download
the .zip file attached to Rick's message. he's not only provided his
solution, but he's provided a "walk through" document, a kind of log of
his process for developing this app and debugging and testing it as he
put the two parts together, to make sure everything was working ok.
Rick, I've decided this is useful enough to me that I'm going to keep
mine running, but I don't feel like taking on the support of another
app just now. so, if you'd like to do it, feel free to finish it off
and upload it to app central; I think it's useful and belongs in the
program enhancements. If you don't feel like doing it though, maybe
let the list know in case someone else would like to take it on?
One thing I'd like to mention to the beginning students: in my
examples, I've always placed the code of the main body of any app at
the start of the .vbs file. You'll find Rick has placed his down into
the .vbs file (a not uncommon practice), marked with a comment.
this is all the same to Window-eyes, no matter where it's placed, it
takes all the statements which are not in a subroutine or function, and
groups them together and executes them as the main body; just something
I thought I should mention now, as I don't ever recall mentioning this
point earlier, and someone may have thought there was no main body
code.
Chip
__________________________________________________________________
From: RicksPlace [mailto:[email protected]]
Sent: Monday, April 18, 2011 4:51 PM
To: [email protected]
Subject: VBScript NotePad App and Loading To App Central
Hi Chip: Here is the Script files for the NotePad script we were
working on in class.
It is unfinished since I did not want to upload it to App Central
unless this is the version that would be a good Production Fit with
anything else up there for NotePad.
Also, since I have not uploaded it I don't have a real ID, ScriptNamed
Website and whatever else goes along with uploading a script properly.
That said, this is getting close and I will check out any docs on
uploading scripts.
I to not want to add to the bloat that is happening with the available
scripts by putting up some test script so will wait until I hear from
you here or in class.
Anyway, it's done for now so it is what it is.
Let me know if you are going to put a real NotePad script up or if you
are going to modify an existing script.
Rick USA
References
1. mailto:[email protected]
2. mailto:[email protected]
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:[email protected] http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
