Gene Wirchenko wrote on 09 dec 2011 in comp.lang.javascript:
[snip]
Sometimes,
this causes problems though less than right after typing the code
in.
Why would that cause problems [stipulating that you understand the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
code?
^^^^
Oh, come on! Typos, and of course,
Modular programming even on the minute scale of common browser
javascript prograsmes, will prevent that.
function tempModule(arguments) {
alert(arguments);
return tempReturnValues; // replace with absolute test-value;
};
If this works, then replace the fmodule with it's dynamic equivlent.
if I am experimenting with features, your stipulation is silly:
This is not a stipulation, it is an advice from years of experience.
*You* used the word "stipulating" above.[/QUOTE]
Quite, but not in the sense in can be called silly, as my stipulation is
just an hypothetical inference to state my hypothesis, not a statement of
fact.
Perhaps, you have missed the point. I am learning JavaScript.
Note the word "learning". That means that I do not know as much about
it as I would like.
This goes for most of us. We all learn. As said I reserve the word learn
for aquiring the right knowledge and/or skill.
By "understanding your code" I mean that you understand what it *should*
do, terribly absent when copying a [voluminous] script code from the web
or book.
I have been entering code from a text
Script code just being text,
and javascript being a scripting language??
Oh, you must mean a printed page?
and working
with it. If I already understand the code, there is little or no
point to entering it. If I do not, then there is from the opportunity
to learn.
So you are trying out script code where both [1] you you do know what it
should do and [2] needs to be debugged, because it is not a correctly
working code?
Having entered some code, it might not work due to:
1) bugs: I have found more than one bug in the code. I am an
experienced P/A, just not in JavaScript yet.
As I surmized.
2) language/browser/other changes since the text was published: The
copyright is 1999, but it is the best text that I have found so far as
to level of detail, and despite its minor errors, it has not flipped
the bozo bit.
Are you sure you want to learn from code from last century?
3) my typos: These can be nasty.
So you don't copy from the web but from a last century book, it seems.
Sinse most present day javascript books are not of high quality, and last
century's ones are even worse, the best you can learn from them is sound
debugging.
And that is what I started to explain in this thread, how to do simple
debugging by inserting breakpoints and remarking out code lines.
It is hardly futile. I do get it debugged, and at this point, I
also learn more about the language. Among other things, knowing
language failure patterns is useful in debugging.
How fatuous! That is exactly what I am doing. However, I am at
the point where some of these exercises are not short bits of code.
Some of them depend on the interaction of many bits. Besides, it is
not enough to be able to handle small bits of code; I need to be able
to handle larger aggregations of code.
At this point you should try modular programming, very feasable in
javascript, and making the testing and understanding of your programme
possible.
Declare the input to output and the interface effects of each module and
make and test that module for all values within the required range. When
satisfied treat that module as a black box and use your modules to
compile a module of the next higher level of modularity.
Is this 1999 code up to this level of loguic or is it just a Gordian knot
of interloping parts of all too linear programing?
