JavaScript guidelines published

  • Thread starter Laurent Bugnion [MVP]
  • Start date
L

Laurent Bugnion [MVP]

Hi,

-Lost said:
Awesome! This has been a long time coming and quite frankly I am glad to see it.

Thanks, Laurent.

-Lost

My pleasure. To be precise, the long time was due more to me than to my
bosses, who agreed quite fast to publishing this. I wanted to review the
guidelines thoroughly before publishing, to make sure that no sensitive
info was published (like developers names etc...). Sorry for the delay.

Greetings,
Laurent
 
L

Laurent Bugnion [MVP]

Hi,
As others have said, a very good start. Of course I have some
personal dislikes here and there but none worth arguing over. :)

Chapter 6 Flow Control references another document that isn't
provided. Any chance you can make that available too?

I think that the Siemens C# guidelines are online somewhere, but I
couldn't find them yet. I will ask.

Greetings,
Laurent
 
L

Laurent Bugnion [MVP]

Hi,

Douglas said:
5.2.1 Rec. 5-101 Declare and initialize variables close to where they
are used.

This would be good advice for languages with block scope. JavaScript
does not have block scope, only function scope, so the recommendation
should be to declare variables at the beginning of the function.

Also see http://javascript.crockford.com/code.html

The reason for this guideline is that our developers are C# developers
mainly. We wanted to encourage the use of consistent conventions in C#
and in JavaScript, this is the main reason. Maybe the wording doesn't
make this clear enough.

Greetings,.
Laurent
 
L

Laurent Bugnion [MVP]

Hi,

I cannot take the time to comment every one of your remarks ;-) but they
are interesting.

Matt said:
As a doc specifically for their project, I can't comment. But if this doc
were to be morphed into a more general document, I would make the following
observations:

- "new Object()" in code should be discouraged but it's in an example in
2.2.3

- alert(), confirm(), and prompt() have their place and shouldn't
necessarily be avoided in production code

We have a special situation: Our licenses are using a lease-based
system, and the lease is renewed using recurrent web service calls. If
the client leaves an alert open too long, he loses the license (because
the web service calls are blocked). Thus, we forbid using alert in that
project.
- Prefixing variable names to indicate type is Old School, and is
questionable in a non-typed language like JS.

We found it invaluable for JavaScript, *because* it is non typed. For
the records, "systems" hungarian notation is discouraged in our C#
guidelines. We made an exception in JavaScript because we think that it
improves readibility greatly.
- Use XML tags for documenting? I would prefer jsdoc syntax.

The reason why we use XML comment is compatibility with C# code. Our
developers are C# developers, we don't want to confuse them with a new
documentation syntax. The lack of support for inline documentation (à la
intellisense for C# XML doc) is a shame, though.
- Combining variable declaration shouldn't be avoided.

- The comment in 5.2.1 of "A variable ought to be declared within the
smallest possible scope to improve the readability of the code and so that
variables are not unnecessarily allocated" seems misguided. A "var i",
whether at the beginning of a function or declared in a for loop, will still
be allocated:
function() {
var i;
if (false) {
for (var j=0; j<10; j++) { alert('unreachable'); }
}
alert(i);
alert(j);
alert(k);
}
Although I often 'var' variables close to where they are used, it would
probably be a better recommendation to declare them at the top of functions.

We think that declaring the variable near to where it is used improves
readibility especially for C# trained developers. For the records, we
have the same guideline in VB, which is also not scoped.
In general, it's not a bad place to start and a group would be better off
with these conventions than none, IMO. But much could be added to this doc
that would be more practical than variable naming conventions, for example.
I intended to extend my own "Best Practices" document at some point to
include more syntax suggestions like those found in this doc, so this may be
a good starting point.

Yes, but we didn't want to publish a "best practice document". This is a
guidelines document and nothing else. You're more than welcome to
elaborate on it!

Greetings,
Laurent
 
L

Laurent Bugnion [MVP]

Hi,

Mister said:
Just out of curiosity what alternatives to alert(), confirm() and
prompt() do you guys use in your production code

We use positioned DIVs for user-oriented message boxes. The target is
IE6+ and Mozilla 1+, so no worries, we know that DHTML and JavaScript
are available for this application.

For debugging messages, we developed a tracing system. Some tracing
messages are kept on the client (we use a self-made console for display,
for reasons of cross browser compatiblity), and some messages can also
be traced on the server. We use a web service for this, and the
server-side tracing system to log the messages (log4net). The
client-side tracing system is not deployed to our clients, but the
server-side tracing system is available, and configurable using the
log4net configuration files (the client-side code is also configured on
the fly using these config files to avoid unnecessary traffic).

Of course we also use alert, confirm and input in the course of
development, but we remove the code for production .

Greetings,
Laurent
 
L

Laurent Bugnion [MVP]

Hi,

Peter said:
Thanks for getting permission to share this.

Peter

You welcome. We escalated quite high to make sure we didn't hurt any
internal policy ;-)

Greetings,
Laurent
 
L

-Lost

Laurent Bugnion said:
Hi,


My pleasure. To be precise, the long time was due more to me than to my bosses, who
agreed quite fast to publishing this. I wanted to review the guidelines thoroughly
before publishing, to make sure that no sensitive info was published (like developers
names etc...). Sorry for the delay.

Your getting around to publishing this more than makes up for any delay on your part.
Sorry is definitely not needed!

Take care!

-Lost
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,767
Messages
2,569,570
Members
45,045
Latest member
DRCM

Latest Threads

Top