I occasionally find the most descriptive name to be a reserved word, so lead it w/ an _underscore, but just realized that capitalizing the first letter is also effective:
Has anyone else done this, and experienced an error therefrom?
I don't know all that much about Javascript, but I do know that I HATE variable names that start capitalized! It's just coding standards I guess, so it's really up to you..
In general (in OO languages anyway), classes begin with a capital, constants are all caps, and the rest (variables and methods/functions are all that's left.. i think) begin lowercased.
Up to you how you want to do it, but capitalizing in Java (not Javascript) might conflict with a class name, like String..
Yeah, Sadiq has a point. There's a very firmly put into place convention of using lowercase first letter for general variables, object members and namespaces. You use an uppercase first letter for classes, and all uppercase for constants. However, with the exception of constants, how to write the rest varies more between langauges. C/C++ and Java traditionally use camelCase. Ruby, as an example, instead uses under_scores. Some programmers use hungarian notation, while some just use object descriptive names, and others use usage descriptive names. But, the constant/class(or constructor in JavaScript)/others follow that pattern pretty much everywhere, unless you look at languages with a very non-C, non-BASIC syntax - languages such as Scheme, J (no, J has nothing to do with Java. It's a derivative of APL), Assembly.
Where are the detailed coding conventions of JavaScript described, anyway?
I haven't learned to ascribe meaning to case, so have no preference, really -- not that I wouldn't like to know why names are presented differently according to their context...
What about element names... does case also apply there?
I'm sure to find out eventually; just wondering if this has been a problem for anyone...
functions,variables are generally written in camelCase(don't know any that ain't).
examples:getElementById,className,nextSibling and so on
Classes are written in 1st letter capital.
example :new Array,new Object,new Image.
which makes it sort of odd how JAVAEOC could say he not encountered any such reserverd words.
another advise from a delphi programmer: is that classes start with T before the object names and the object them self is then without a T.
and arguments send to function start with an a.
Well, the coding conventions for JavaScript are something like this:
- Object members beginning with underscore generally was Netscape specific and you were discouraged to use them.
- Object members beginning with double underscores or triple underscores were Netscape internal members, and should preferably not be used even if you were programming Netscape specific code.
- Constructors use uppercase first letter.
- Anything else use a lowercase first letter.
- You use uppercase letter for the first letter in each word in an identifier, lowercase for the rest. This goes for acronyms and abbreviations as well.
- However, constants use all uppercase and underscore as word separator.
- Functions and methods SHOULD contain a verb while anything else SHOULD NOT.
- There are some common single-letter variable names that are pretty standard:
error - e
event - e
iterators - i,j,k
length - l
horizontal coordinate - x
vertical coordinate - y
regular expression - re
- Microsoft encourages usage of hungarian notation. That means that you prefix identifiers depending on their supposed content type:
a - array
s - string
o - object
b - boolean
i - integer number
(f - floating point number)
n - number
re - regular expression
fn - function
The problem with this approach is that you might want to store data of another type in the same variable.
I personally use hungarian notation when I want to make my code clear for others, since it makes things easier to follow at times.
Another coding convention that has outcristallised for JavaScript is that opening braces in general are placed on the same line as the control structure instead of on a new line, and that the ending brace should be placed at the same level as the control structure, while the contents have an additional indentation level. You most commonly see an indentation of four spaces, though you can find two spaces or a singe tab as well. Three spaces is very unusual, but you might encounter it among some developers from places that uses that convention. You are encouraged to always use a semicolon to close a statement that is not autoterminating. The only places (according to common coding conventions) you may leave them out are when the next non-whitespace character is a closing brace.
As for commenting, use single line comments for code comments, use block comments only for very long running explanatory text or introductory headers. Following these conventions makes it easier to use block comments when testing and debugging the code, so this convention is something that has come out of pragmatism.
Well, I might have forgotten something, but otherwise that should be fairly complete.
Well, in general, they are the blocks or the control structures:
Take the if statement for instance:
Code:
if (condition) statement
Here you have a statement containing a statement. The if statement is autoterminating, because the statement requires termination. Say that the statement is alert('inside the statement'). That statement needs to be terminated, so you add a semicolon after it to terminate it. However, if the if statement was not autoterminated, you would need to add another semicolon to end the if statement, thus giving the following code:
Code:
if (condition) alert('inside the statement');;
However, we already know that when the statement is terminated the if statement is terminated as well, so there's no need for adding a terminating semicolon to it. Thus we end up with just:
Code:
if (condition) alert('inside the statement');
Same goes for if the statement was a block statement. If the if statement wasn't autoterminating you would need to add a semicolon after the closing brace, like this:
Code:
if (condition) {
statementList
};
Which again is redundant since we already know the if statement must be terminated when the statement is terminated.
That was an example of when closing the inner statment must lead to closing of the outer statement as well. The function definition and the block statment work the other way: when the outer statement is terminated, you know that the inner statement is terminated. Thus:
Code:
function example(){
statementList
return true;
}
The red marked semicolon is not needed for termination, since we know that when the outer statement is terminated (as indicated by the closing brace) the inner statement by necessity must be terminated as well.
Before you post, read our: 
Oh, I see; would that be true for all JS Statements [if(), which(), for(), etc.], and does that apply only to such statements?
