While I realize that each language has its own convention for indentation, I can't help but be annoyed with something I've recently discovered. Consider this code from the PHP manual:
switch ($i) {
case "apple":
echo "i is apple";
break;
case "bar":
echo "i is bar";
break;
case "cake":
echo "i is cake";
break;
}
Notice that each case is indented from the switch statement. This makes sense, as the code is easier to read and the body of the block is contained one level inside of it.
However, when I test the equivalent JavaScript switch statement in JSLint:
switch (i) {
case "apple":
alert("i is apple");
break;
case "bar":
alert("i is bar");
break;
case "cake":
alert("i is cake");
break;
}
...it displays an error telling me that it should appear like this instead:
switch (i) {
case "apple":
alert("i is apple");
break;
case "bar":
alert("i is bar");
break;
case "cake":
alert("i is cake");
break;
}
It seems counterintuitive, as each case is now inline with the switch block itself. I can't imagine any reason why this would be considered better, much less trigger an error.
Is JSLint in err, or is it just following convention? If the latter is true, why wouldn't the convention be to indent for clarity?
It's your code. Format it how you want to. Use jsLint, but if you disagree that its recommendations improve your code, don't implement them. jsLint hurts your feelings.
As long as your indenting can be logically justified you should indent in the style you prefer. If JSLint really complains about this then it's being overly pedantic.
It's just convention for JS (as JSLint defines convention). Personally, I think PHP would be in the wrong here (dunno if the manual follows any sort of convention, I know the standard library doesn't). I prefer the JS style because it can get really nasty if you're in a few nested blocks. For example (PHP code):
class Foo{
function Bar($arr) {
foreach($arr as $item) {
switch ($item) {
case "foo":
// Do something
break;
// You get the idea
Ultimately, your choice. I wouldn't use the PHP manual as a style guide; if you can't use different styles for different languages, use the well-defined JS style.
While formatting is important, in the end it's your formatting. Do it how you like. The particular style you choose is a personal choice and many styles can be "good". However, any "good" formatting style must be consistent - pick the rules you like and stick to them.
It's kind of funny to me how debates rage over things like placing { on the same line as the preceeding code or not, or "cuddling curly braces" around an else
. I think only communists place a { on the same line as their if
statement. :)
Extra whitespace is parsed out of JavaScript and PHP when they are interpreted, so you can make your code as ugly as you'd like. Personally I prefer to add extra curly brackets to my switch statements so that I don't miss fall-through errors:
switch ($someVar)
{
case 'value':
{
//your code here
} break;
case 'something':
{
//more code here
}
case 'something else':
{
//some more code here
} break;
default:
{
//default code here
} break;
}
Scanning down the code at the end braces allows me to check If I added the correct break statements. You can see that the 'something'
case is missing a break statement (maybe on purpose, maybe a mistake).
Some will disagree with this format, but that's really what I'm getting at. The format doesn't matter that much. The parsers are pretty forgiving. Find something that works for you and stick to it.
In Crockford's book, he states that blocks do not introduce a new scope. "JSLint expects blocks with function,if,switch,while,for,do and try statements and nowhere else."
Also that
if (condition){
statements;
}
Is the recommended method of doing blocks; as it is "more resilient". I highly doubt it was structured that way in error.
It's his Java background leaking through. The JSLint way mimics the official Java conventions for switch case. I prefer your first example, but I'm learning to tolerate the JSLint way.
I also found this very confusing, and found this reason in Douglas Crockford's Code Conventions for the JavaScript Programming Language at http://javascript.crockford.com/code.html
Clauses (case, catch, default, else, finally) are not statements and so should not be indented like statements.