On Aug 24, 11:29 am, Klaus Hartl <[EMAIL PROTECTED]> wrote:
>
> I do not follow all of it - on the other hand I do not know of anything
> similiar:http://javascript.crockford.com/code.html
>
> (Crockford of course)
>
Thanks Klaus.
I am just becoming familar with Crockford and I can see he is very
practical minded, just like me. :-)
Excellent link with good information in there. I disagree with a few
of the items, but overall a great piece of consolidated work.
Here are other rules of thumbs or items I have a different take than
Crockford
- Usage of Underscore.
Using underscore which Crockford denotes as "private", traditionally,
it denotes the "primitive" or "base" or "abstract" version of the
entity, which of course, implies private access. I think most API
developers have follow this practice, including jQuery and as I see
some of the plug-in authors.
- Scoping of Variables
Douglas excellently suggest to lump all your variables at the top
before they are used. Not only does it help in reading code, this is
the basically the mindset of an original C programmer where you had no
choice but to lump all your references variables at the top.
However, in my view, it is better to locally scope your variables for
two reasons: 1) It helps in seeing the blocks where variables apply,
and 2) very importantly, it helps in the modulization process, i.e,
you can pull the block of code and make it a function without trying
to figure out which top variables applie to the block.
True, JS does not support local scoping, and this can get you in
trouble in designs too - using the same variable name twice for two
different things conflicting with your design intentions, but that is
where the moduliztion comes in and helps resolves this conflicts.
- Variable initialization
It is good practice to get use to the ideal of always initializing
your variables. Many languages, especially those like JavaScript with
RTEs (Run Time Engines), which typically automatically zero out all
memory variables.
However from a programmer's system logic perspective:
var currentEntry = 0; // currently selected table entry
is "better" then
var currentEntry; // currently selected table entry
If someone every wrote a real compiler for JavaScript, the benefits
of initialization will become very apparent. If the programmer
switches languages alot, it is good practice to always think the same
way.
- Variable and Function Naming or Function Prototyping
Crockford did not touch base with this - probably because it is always
been a source of contention possibly, especially when OOPS was gaining
in the industry.
But if you take his top lumping of vairables to heart, using his
example:
var currentEntry; // currently selected table entry
var level; // indentation level
var size; // size of table
then when a code reads this, what "type" are these. Are they
numbers, strings, array, objects?
Yes, some names naturally imply "numeric", like level and size. But
what about?
var data; // currently selected table entry
worst, the coder is lazy and doesn't use inline comments:
var data;
Then it becomes harder (takes extra mental steps) to find out what
that is.
The benefits comes into play especially with function prototyping and
I will use real life scenario and main reason I brought this up. In
jQuery, it has the .ajax() events and use the error event function as
an example it is prototyped as:
function(xml, status, e)
well, a good programmer can somewhat guess at what status and e are,
one is a string and one is an number but what about XML? Is this an
XML structure document? XML has really nothing to do with XML object
or structure, and as it turns out, e is a string!!
To make sense of that, I have it in my ajax call, like so
$.ajax({
complete: function(httpReq, sStatus) {
wcat.logln("http status: "+obj.status);
},
success: function(response){
},
error: function(httpReq, sStatus, sError){
}
});
Just makes it easier for everyone when it comes to reading and
maintaining code to setup it up so it becomes your immediate
"reference guide." People who write long lasting code for themselves
or others, and they may have to revisit it in the future, greatly
appreciate the early efforts taken to make it more readable.
- Function size
If the function size is "long" (what is long?) meaning lots of lines,
it should be broken up. In fact, some rules requires that if its
longer than 20-25 lines, its TOO long. For the same reason Doug
suggest less than 80 characters line, the 80x25 limit was based on old
dumb terminal console displays. Today, I still use console windows
for my editor and under windows I have it at 45 rows, so my functions
are typically no greater than 35-40 lines max. I want to be able to
see a function in one terminal page view.
Anyway. I'm going off the deep in now. :-)
--
HLS
