By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,106 Members | 1,355 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,106 IT Pros & Developers. It's quick & easy.

JavaScript guidelines published

P: n/a
Hi group,

In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Guidelines.pdf

Please note the following:

* The purpose of publishing this document on the World Wide Web is to
promote and encourage consistent practices in the JavaScript programming
community.

* We publish this document as information only. Siemens will not accept
any responsibility regarding its content.

* The guidelines are recommendations based on our experience, and may or
may not make sense in the context of a different company, or a different
project. Their intent is to be a source of inspiration for other
JavaScript developers, and nothing more.

* The guidelines are dated 20th of April 2004, which is quite some time
ago. I think that most of the recommendations are still valid, but of
course additions can be made.

HTH,
Laurent
--
Laurent Bugnion [MVP ASP.NET]
Software engineering, Blog: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch
Feb 5 '07 #1
Share this Question
Share on Google+
26 Replies


P: n/a
Laurent Bugnion [MVP] wrote:
In agreement with the head of our R&D department, I published my
firm's JavaScript Coding Guidelines.
Fantastic!
Although I don't agreement with all of the conventions, I think that
publishing documents like this could give someone a good place to start from
in trying to make their coding more consistent, and in the end that will be
nothing but positive. Thank you for sharing.

Do you use any tool to check that js source files adhere to these standards?
What positive impact has this document had in your work environment - do
people follow it? Is it enforced? Was there any push back against it?

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Feb 5 '07 #2

P: n/a
Matt,

Matt Kruse wrote:
Laurent Bugnion [MVP] wrote:
>In agreement with the head of our R&D department, I published my
firm's JavaScript Coding Guidelines.

Fantastic!
Although I don't agreement with all of the conventions, I think that
publishing documents like this could give someone a good place to start from
in trying to make their coding more consistent, and in the end that will be
nothing but positive. Thank you for sharing.
To be honest, I also don't agree with all of them (though I strictly
adhere to them in my job, and use my own set in my private projects).
Guidelines like this are a teamwork, and sometimes we had to compromise.

Do you use any tool to check that js source files adhere to these standards?
We don't, but we used code reviews, where one of the criteria tested was
the enforcement of these guidelines.
What positive impact has this document had in your work environment - do
people follow it?
Yes, very much so. In fact, the situation was relatively easy, because
most of my coworkers didn't have much (if any) experience with
JavaScript, so they kind of believed me when I told them that this was
the way to go ;-) Seriously, the people I worked with (and coordinated)
in that project did an excellent job. For the records, the application
is an ASP.NET web application used for building automation. The server
part relies on an existing unmanaged C++ product which we extended with
..NET code. We rely on .NET remoting for communication between the web
server and the C++ server, and make quite intensive use of web services
between the client and the web server. We already had the web
application up and running for more than 2 weeks in intensive test
conditions without any trouble. We wrote about 15000 lines of code (not
counting generated code, for which we wrote a JavaScript cross compiler).

The development time was about 1.5 years
Is it enforced? Was there any push back against it?
No push back. All the developers are professionals with many years
experience in other languages (C++, Java, C# mostly) and all of them
understand the value of guidelines.

Greetings,
Laurent
--
Laurent Bugnion [MVP ASP.NET]
Software engineering, Blog: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch
Feb 5 '07 #3

P: n/a
"Laurent Bugnion [MVP]" <ga*********@bluewin.chwrote in message
news:45**********@news.bluewin.ch...
Hi group,

In agreement with the head of our R&D department, I published my firm's JavaScript
Coding Guidelines. I work for Siemens Building Technologies. We developed these
guidelines for a web application project in 2004, based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Guidelines.pdf
Awesome! This has been a long time coming and quite frankly I am glad to see it.

Thanks, Laurent.

-Lost
Feb 5 '07 #4

P: n/a
"Matt Kruse" <ne********@mattkruse.comwrote in message
news:eq*********@news1.newsguy.com...
Laurent Bugnion [MVP] wrote:
>In agreement with the head of our R&D department, I published my
firm's JavaScript Coding Guidelines.

Fantastic!
Although I don't agreement with all of the conventions, I think that publishing
documents like this could give someone a good place to start from in trying to make
their coding more consistent, and in the end that will be nothing but positive. Thank
you for sharing.
Really? What conventions do you not agree with and why?

I would love to keep a running tally of all the amendments "the JavaScript gurus" like
yourself, <and you know who you are guys>, think should be modified in this document.

I would be glad to publish the revisions in whatever format was deemed acceptable
(assuming Laurent does not have the time to update it himself). I figured it could be a
separate project unto the Siemens guidelines.

-Lost
Feb 5 '07 #5

P: n/a
VK
On Feb 5, 6:20 pm, "Laurent Bugnion [MVP]" <galasoft...@bluewin.ch>
wrote:
Hi group,

In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.

<http://www.galasoft-lb.ch/myjavascript/Siemens_SBT_JavaScript_Coding_Guidelines.pdf>
Thanks for that.

Feb 5 '07 #6

P: n/a
In comp.lang.javascript message <45**********@news.bluewin.ch>, Mon, 5
Feb 2007 16:20:17, "Laurent Bugnion [MVP]" <ga*********@bluewin.ch>
posted:
>
In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.
Good, largely. But :-

Does Siemens not use ISO 8601 date format? "08.11.2004" is a form not
commonly used in English, either.

3-101, 4-103 are bad choices <g>.

3-204 - that's nothing : in Pascal one can do
const true = false ; false = not true ;

4-101 - often disregarded elsewhere. I suggest that each file should
also have a trailer block, as a guard against accidental incomplete
copies. "// End" would suffice.

4-102 - The meaning is clear, and good; but the statement is defective.

11-203 - How about continuation lines (where FORTRAN would use a C)?

Especially for the benefit of those using slow links, ISTM worth
indicating size by a link to a PDF. Some PDFs are big!. Yours is 70kB.
Could/should the document be cited in the newsgroup FAQ?

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zipTimo Salmi's Turbo Pascal FAQ.
Feb 5 '07 #7

P: n/a
-Lost wrote:
Really? What conventions do you not agree with and why?
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

- Prefixing variable names to indicate type is Old School, and is
questionable in a non-typed language like JS.

- Use XML tags for documenting? I would prefer jsdoc syntax.

- 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.

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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Feb 5 '07 #8

P: n/a
On Feb 6, 1:20 am, "Laurent Bugnion [MVP]" <galasoft...@bluewin.ch>
wrote:
Hi group,

In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Script_Coding_...
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?
--
Rob

Feb 6 '07 #9

P: n/a
Laurent Bugnion [MVP] wrote:
Hi group,

In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Guidelines.pdf
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
Feb 6 '07 #10

P: n/a
On Feb 6, 5:37 am, Douglas Crockford <nos...@sbcglobal.netwrote:
Laurent Bugnion [MVP] wrote:
Hi group,
In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.
http://www.galasoft-lb.ch/myjavascri...Script_Coding_...

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 seehttp://javascript.crockford.com/code.html
Dean Edwards made a point against declaring at the top of a function.
When all the variables are at the top and some middle section of the
function is refactored to another location, the variable declarations
don't go with the refactored code. Then the variables are implicit
globals.

Peter

Feb 6 '07 #11

P: n/a
Peter Michaux wrote:
Dean Edwards made a point against declaring at the top of a function.
When all the variables are at the top and some middle section of the
function is refactored to another location, the variable declarations
don't go with the refactored code. Then the variables are implicit
globals.
I agree for variables that are used only within "block scope". If the code
is ever copied, the lack of 'var' declarations might cause a problem.

Since Javascript doesn't care if you declare a variable multiple times with
'var', I do it every time in loops like:
for (var i=0; i<len; i++)

For variables that are used throughout a function, it would be a better
recommendation to declare them at the top rather than when they are first
used.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Feb 6 '07 #12

P: n/a
Lee
Peter Michaux said:
>
On Feb 6, 5:37 am, Douglas Crockford <nos...@sbcglobal.netwrote:
>Laurent Bugnion [MVP] wrote:
Hi group,
In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.
>http://www.galasoft-lb.ch/myjavascri...Script_Coding_...

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 seehttp://javascript.crockford.com/code.html

Dean Edwards made a point against declaring at the top of a function.
When all the variables are at the top and some middle section of the
function is refactored to another location, the variable declarations
don't go with the refactored code. Then the variables are implicit
globals.
A function shouldn't be so large and complex that some middle section
of it would be pulled out, or if it is, the declarations should still
be visible in the same screen full of text, and the person yanking
them should take responsibility for including the declarations.
--

Feb 6 '07 #13

P: n/a
On Feb 5, 10:20 am, "Laurent Bugnion [MVP]" <galasoft...@bluewin.ch>
wrote:
Hi group,

In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Script_Coding_...

Please note the following:

* The purpose of publishing this document on the World Wide Web is to
promote and encourage consistent practices in the JavaScript programming
community.

* We publish this document as information only. Siemens will not accept
any responsibility regarding its content.

* The guidelines are recommendations based on our experience, and may or
may not make sense in the context of a different company, or a different
project. Their intent is to be a source of inspiration for other
JavaScript developers, and nothing more.

* The guidelines are dated 20th of April 2004, which is quite some time
ago. I think that most of the recommendations are still valid, but of
course additions can be made.

HTH,
Laurent
--
Laurent Bugnion [MVP ASP.NET]
Software engineering, Blog:http://www.galasoft-LB.ch
PhotoAlbum:http://www.galasoft-LB.ch/pictures
Support children in Calcutta:http://www.calcutta-espoir.ch
Just out of curiosity what alternatives to alert(), confirm() and
prompt() do you guys use in your production code

Feb 6 '07 #14

P: n/a
In comp.lang.javascript message <eq*********@news2.newsguy.com>, Mon, 5
Feb 2007 14:42:47, Matt Kruse <ne********@mattkruse.composted:
>- Prefixing variable names to indicate type is Old School, and is
questionable in a non-typed language like JS.
Bearing in mind that, in the context given, code is written to be read
as well as executed, ISTM that where a variable is intended to be of
only one type during its lifetime it could be well to indicate that
thusly, as an aid to readers determining whether the code which was
written is the code which ought to have been written.

One might also say that, where the value of a variable will only be used
within a very short amount of code, it may be given a very short and
meaningless name.

Example : L = List.length ; for (J=0; J<L; J++) Total += List[J] ;

>- Combining variable declaration shouldn't be avoided.
Should not be forbidden. In code about Hamiltonians,
var w, x, y, z ;
makes sense. But often it is reasonable to avoid combinations.

>- 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:
But that's not important for the readability of the code.
Unfortunately, AFAIR, there's no un-declare.

In fact, Algol was good there; if a variable J was going to be needed
only in a short part of the code, one could surround that part with
begin var J : integer ; ... end ; . If the next section needed
var X : real ; then the compiler probably would make J & X share
storage, for what it's worth.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.
Feb 6 '07 #15

P: n/a
"Mister Joe" <mr*********@gmail.comwrote in message
news:11**********************@k78g2000cwa.googlegr oups.com...
On Feb 5, 10:20 am, "Laurent Bugnion [MVP]" <galasoft...@bluewin.ch>
wrote:
>Hi group,

In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Script_Coding_...

Please note the following:

* The purpose of publishing this document on the World Wide Web is to
promote and encourage consistent practices in the JavaScript programming
community.

* We publish this document as information only. Siemens will not accept
any responsibility regarding its content.

* The guidelines are recommendations based on our experience, and may or
may not make sense in the context of a different company, or a different
project. Their intent is to be a source of inspiration for other
JavaScript developers, and nothing more.

* The guidelines are dated 20th of April 2004, which is quite some time
ago. I think that most of the recommendations are still valid, but of
course additions can be made.

HTH,
Laurent
--
Laurent Bugnion [MVP ASP.NET]
Software engineering, Blog:http://www.galasoft-LB.ch
PhotoAlbum:http://www.galasoft-LB.ch/pictures
Support children in Calcutta:http://www.calcutta-espoir.ch

Just out of curiosity what alternatives to alert(), confirm() and
prompt() do you guys use in your production code
I wondered that for a moment as well. My guesses:

alert() is normally (well, for me anyway) used during debugging, in fact it is easier to
debug with alert than it is anything else. Therefore no need for alert() in production
code.

confirm() and prompt() could both take the guise of forms if user input is at all
necessary. For example, if I needed to ask you a serious of demographic questions, what
would you rather endure: 30 prompts or confirms or a nicely formatted display of text
inputs, radios, or check boxes? I definitely think the latter.

So, there is my $0.02.

-Lost
Feb 7 '07 #16

P: n/a
Sorry! I should have snipped Laurent's signature.

*shakes finger at Mister Joe*

-Lost
Feb 7 '07 #17

P: n/a
On Feb 5, 7:20 am, "Laurent Bugnion [MVP]" <galasoft...@bluewin.ch>
wrote:
Hi group,

In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Script_Coding_...
Thanks for getting permission to share this.

Peter

Feb 7 '07 #18

P: n/a
On Feb 6, 8:31 am, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
wrote:
One might also say that, where the value of a variable will only be used
within a very short amount of code, it may be given a very short and
meaningless name.

Example : L = List.length ; for (J=0; J<L; J++) Total += List[J] ;
I agree completely. I use very short names just like this to point out
the short-lived nature of the variable.

In fact, Algol was good there; if a variable J was going to be needed
only in a short part of the code, one could surround that part with
begin var J : integer ; ... end ; . If the next section needed
var X : real ; then the compiler probably would make J & X share
storage, for what it's worth.
JavaScript 1.7 let statement is similar for defining block scope. Not
the same as Algol but there you go.

Peter

Feb 7 '07 #19

P: n/a
On Feb 6, 5:06 pm, "-Lost" <spam_ninjaREMOV...@REMOVEMEcomcast.net>
wrote:
"Mister Joe" <mrjoefri...@gmail.comwrote in message

news:11**********************@k78g2000cwa.googlegr oups.com...
On Feb 5, 10:20 am, "Laurent Bugnion [MVP]" <galasoft...@bluewin.ch>
wrote:
Hi group,
In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.
>http://www.galasoft-lb.ch/myjavascri...Script_Coding_...
Please note the following:
* The purpose of publishing this document on the World Wide Web is to
promote and encourage consistent practices in the JavaScript programming
community.
* We publish this document as information only. Siemens will not accept
any responsibility regarding its content.
* The guidelines are recommendations based on our experience, and may or
may not make sense in the context of a different company, or a different
project. Their intent is to be a source of inspiration for other
JavaScript developers, and nothing more.
* The guidelines are dated 20th of April 2004, which is quite some time
ago. I think that most of the recommendations are still valid, but of
course additions can be made.
HTH,
Laurent
--
Laurent Bugnion [MVP ASP.NET]
Software engineering, Blog:http://www.galasoft-LB.ch
PhotoAlbum:http://www.galasoft-LB.ch/pictures
Support children in Calcutta:http://www.calcutta-espoir.ch
Just out of curiosity what alternatives to alert(), confirm() and
prompt() do you guys use in your production code

I wondered that for a moment as well. My guesses:

alert() is normally (well, for me anyway) used during debugging, in fact it is easier to
debug with alert than it is anything else.
console.log in Safari and in Firefox with Firebug is at least as easy
and I think easier. It saves having to click to close the alert all
the time. Firebug now supplies a JS file to emulate this behavior in
other browsers. I haven't tried that however.

Peter

Feb 7 '07 #20

P: n/a
Hi,

-Lost wrote:
"Laurent Bugnion [MVP]" <ga*********@bluewin.chwrote in message
news:45**********@news.bluewin.ch...
>Hi group,

In agreement with the head of our R&D department, I published my firm's JavaScript
Coding Guidelines. I work for Siemens Building Technologies. We developed these
guidelines for a web application project in 2004, based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Guidelines.pdf

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
Feb 7 '07 #21

P: n/a
Hi,

RobG wrote:
On Feb 6, 1:20 am, "Laurent Bugnion [MVP]" <galasoft...@bluewin.ch>
wrote:
>Hi group,

In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Script_Coding_...

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?
--
Rob
I think that the Siemens C# guidelines are online somewhere, but I
couldn't find them yet. I will ask.

Greetings,
Laurent
Feb 7 '07 #22

P: n/a
Hi,

Douglas Crockford wrote:
Laurent Bugnion [MVP] wrote:
>Hi group,

In agreement with the head of our R&D department, I published my
firm's JavaScript Coding Guidelines. I work for Siemens Building
Technologies. We developed these guidelines for a web application
project in 2004, based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Guidelines.pdf


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
Feb 7 '07 #23

P: n/a
Hi,

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

Matt Kruse wrote:
-Lost wrote:
>Really? What conventions do you not agree with and why?

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
Feb 7 '07 #24

P: n/a
Hi,

Mister Joe wrote:
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
Feb 7 '07 #25

P: n/a
Hi,

Peter Michaux wrote:
On Feb 5, 7:20 am, "Laurent Bugnion [MVP]" <galasoft...@bluewin.ch>
wrote:
>Hi group,

In agreement with the head of our R&D department, I published my firm's
JavaScript Coding Guidelines. I work for Siemens Building Technologies.
We developed these guidelines for a web application project in 2004,
based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Script_Coding_...

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
Feb 7 '07 #26

P: n/a
"Laurent Bugnion [MVP]" <ga*********@bluewin.chwrote in message
news:eq**********@zrha118x.zrh.siemens.ch...
Hi,

-Lost wrote:
>"Laurent Bugnion [MVP]" <ga*********@bluewin.chwrote in message
news:45**********@news.bluewin.ch...
>>Hi group,

In agreement with the head of our R&D department, I published my firm's JavaScript
Coding Guidelines. I work for Siemens Building Technologies. We developed these
guidelines for a web application project in 2004, based on our C# guidelines.

http://www.galasoft-lb.ch/myjavascri...Guidelines.pdf

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

Thanks, Laurent.
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
Feb 7 '07 #27

This discussion thread is closed

Replies have been disabled for this discussion.