Ответ 1
Это ваш код. Отформатируйте его так, как вы хотите. Используйте jsLint, но если вы не согласны с тем, что его рекомендации улучшают ваш код, не выполняйте их. jsLint повреждает ваши чувства.
Пока я понимаю, что у каждого языка есть своя конвенция для отступов, я не могу не раздражаться тем, что я недавно обнаружил. Рассмотрим этот код из руководства PHP:
switch ($i) {
case "apple":
echo "i is apple";
break;
case "bar":
echo "i is bar";
break;
case "cake":
echo "i is cake";
break;
}
Обратите внимание, что каждый случай имеет отступ от оператора switch. Это имеет смысл, так как код легче читать, а тело блока содержит один уровень внутри него.
Однако, когда я тестирую эквивалентный оператор switch JavaScript в JSLint:
switch (i) {
case "apple":
alert("i is apple");
break;
case "bar":
alert("i is bar");
break;
case "cake":
alert("i is cake");
break;
}
... он показывает ошибку, сообщающую мне, что он должен выглядеть следующим образом:
switch (i) {
case "apple":
alert("i is apple");
break;
case "bar":
alert("i is bar");
break;
case "cake":
alert("i is cake");
break;
}
Это кажется противоречивым, поскольку каждый случай теперь встроен в сам блок коммутатора. Я не могу себе представить, почему это будет считаться лучше, а тем более вызывать ошибку.
Является ли JSLint ошибочным, или это просто соответствует соглашению? Если последнее верно, то почему соглашение не должно быть отступом для ясности?
Это ваш код. Отформатируйте его так, как вы хотите. Используйте jsLint, но если вы не согласны с тем, что его рекомендации улучшают ваш код, не выполняйте их. jsLint повреждает ваши чувства.
В книге Крокфорда он утверждает, что блоки не вводят новую область. "JSLint ожидает блоки с функцией, если, переключать, пока, для, делать и пробовать утверждения и нигде больше".
Кроме того,
if (condition){
statements;
}
Является рекомендуемым методом выполнения блоков; поскольку он "более устойчив". Я очень сомневаюсь, что он был построен таким образом по ошибке.
Пока ваш отступы могут быть логически обоснованы, вы должны отступать в стиле, который вы предпочитаете. Если JSLint действительно жалуется на это, то это слишком педантично.
Хотя форматирование важно, в конце концов это ваше форматирование. Сделайте это, как вам нравится. Особый стиль, который вы выбираете, является личным выбором, и многие стили могут быть "хорошими". Однако любой "хороший" стиль форматирования должен быть последовательным - выберите правила, которые вам нравятся, и придерживайтесь их.
Мне как-то смешно, как дебаты бушуют над такими вещами, как размещение {в той же строке, что и предыдущий код или нет, или "обнимание фигурных скобок" вокруг else
. Я думаю, что только коммунисты размещают {в той же строке, что и их утверждение if
.:)
Это просто соглашение для JS (поскольку JSLint определяет соглашение). Лично я считаю, что PHP был бы здесь не так (не знаю, если руководство следует за любым соглашением, я знаю, что стандартная библиотека этого не делает). Я предпочитаю стиль JS, потому что он может стать действительно неприятным, если вы находитесь в нескольких вложенных блоках. Например (код PHP):
class Foo{
function Bar($arr) {
foreach($arr as $item) {
switch ($item) {
case "foo":
// Do something
break;
// You get the idea
В конечном счете, ваш выбор. Я бы не использовал руководство PHP как руководство по стилю; если вы не можете использовать разные стили для разных языков, используйте четко определенный стиль JS.
Экстра-пробелы анализируются из JavaScript и PHP, когда они интерпретируются, поэтому вы можете сделать свой код столь же уродливым, как хотелось бы. Лично я предпочитаю добавлять дополнительные фигурные скобки к моим операторам switch, чтобы я не пропустил ошибки падения:
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;
}
Сканирование кода в концевых скобках позволяет проверить, добавлены ли правильные инструкции break. Вы можете видеть, что в случае 'something'
отсутствует оператор break (возможно, специально, возможно, ошибка).
Некоторые не согласятся с этим форматом, но это действительно то, что я получаю. Формат не имеет большого значения. Парсеры довольно прощающие. Найдите то, что работает для вас, и придерживайтесь его.
Это его фон Java протекает. Способ JSLint имитирует официальные соглашения Java для случая коммутатора. Я предпочитаю ваш первый пример, но я учусь терпеть путь JSLint.
Я также нашел это очень запутанным и нашел эту причину в кодах соглашений Дугласа Крокфорда для языка программирования JavaScript на http://javascript.crockford.com/code.html
Клаузулы (case, catch, default, else, finally) не являются операторами и поэтому не должны быть отступом как утверждения.