Зачем нужны javasctipt условные обозначения или стиль?

Question

Предположим, у меня есть написать функцию javscript:

function(){ 
    var a=1; 
    var sum=1; 
    for(var i=0;i<6;i++){ 
     sum=sum+a+1; 
    } 
    console.log(sum); 
} 

однако, кто-то рекомендовать писать эту функцию, как это:

function() { 

    var a = 1; 
    var sum = 1; 
    for (var i = 0; i < 6; i++) { 
     var sum = sum + a +1; 
    } 
    console.log(sum); 

} 

с большим пустым пространством, я знаю, это правило, но я не знаю, как это работает, или что я могу извлечь из этого?

Answer 1

Это вопрос мнения, что хорошо стиль есть, но в общем смысле выбор стиль и последовательное следование за ним на протяжении всего кода упрощает чтение (как для других людей, так и для вас, когда вы вернетесь к нему позже).

В моем опыте большинство людей находят код более удобным для чтения с дополнительными пространствами, как показано в вашем втором примере.

Мне не нравится оставлять пробег между function и (). Или, где есть имя функции, я не помещаю пробел между именем и круглыми скобками: function someName().

Обратите внимание, что с современными редакторами кода, которые имеют подсветку синтаксиса (например, Stack Overflow), это намного проще, чем раньше было читать код, который не имеет пробелов. Сравните следующие два:

for(var i=0;i<6;i++) 

for(var i=0;i<6;i++)

Чтение и редактирование последнего, все в черно-белом, действительно раздражает меня, но я не против цветной версии где-нибудь рядом, как много. Я по-прежнему предпочитаю его с дополнительными пространствами.

я хотел бы сделать некоторые изменения в вашей функции:

function() { 
    var a = 1, 
     sum = 1, 
     i; 

    for(i = 0; i < 6; i++){ 
     sum += a + 1; 
    } 
    console.log(sum); 
} 

Answer 2

Преимущество стиля кодирования - улучшенная читаемость. Неважно, какой стиль вы решите придерживаться, пока вы придерживаетесь единообразного стиля и можете соглашаться с вашими коллегами по его читаемости, что не всегда легко.

Answer 3

Возможно, вам стоит больше узнать о закрытии javascript, и вы можете следовать "Google Javascript Style Guide".

Answer 4

Следуя единообразным правилам стиля, когда кодирование облегчает чтение кода и помогает вам писать красивый код, а другим - понимать (и любящий!) Ваш код.

Наверняка есть множество ресурсов в сети (только прибегая к помощи на некоторое время вы получите некоторые JavaScript руководства или руководства), но это одна довольно легко, просто и полная:

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

Answer 5

Это не правило. Это просто стиль оформления кодировки. Вам не нужно следовать, если вы этого не хотите. Но этот стиль может сделать ваш код более читаемым, более простым в обслуживании и более чистым. Для меня я предпочитаю иметь пространство, а не узкие буквы. Опять же, это не правило.

Answer 6

Стиль кодирования всегда очень личный; одному человеку нравится сжатый код, чтобы они могли видеть как можно больше на одном экране, другому нужны открывающие и закрывающие фигурные скобки на отдельной линии и т. д.

Когда вы только кодируете себя, вы должны выбрать то, что лучше для вас , Но когда вы начинаете работать в командах, а другие должны поддерживать ваш код и наоборот, важно согласиться на один стиль кодирования ... и это может быть сложно.

Я сидел в обсуждениях стиля кодирования, и они очень неудобны, потому что вы отказываетесь от своих личных предпочтений, хотя и для большего блага. После короткого момента дискомфорта вы привыкнете к этому ;-)

Answer 7

Эти условные обозначения кодирования предназначены для людей, они повышают читаемость. Предположим, что я написал такое выражение:

x=(a*b/2)+m-n+c*(d/e); 

Он выглядит неуклюжим и трудным для чтения. Было бы легче понять, если бы мы использовали пробелы вокруг операторов, как это:

x = (a * b/2) + m - n + c * (d/e); 

Снова используя пустую строку увеличивает читаемость обозначая секции. Например:

function foo() { 
    var a; 
    var b; 
    // a blank line here to specify the end of variable declarations 
    if (some_cond) { 

    } else if (another_cond) { 

    } 
    // another blank line to specify end of some logic 
    //more codes here; 
} 

Если вы не будете следовать этим правилам, и все члены команды не согласны с каким-то конвенции, то это будет очень трудно поддерживать большой проект в течение длительного времени.

Наконец, обратите внимание, что соглашения не предназначены для компиляторов, они предназначены для людей. Вот почему это называется руководством по кодированию, а не синтаксисом языка.

Answer 8

1. Вторая версия не эквивалентна первой, так как она объявляет переменную внутреннюю «SUM», если Javascript не сделает то, что он говорит на олове с этим.

2. Дополнительные пустые строки ничего не вносят, ИМХО, но я, вероятно, не умру в канаве. Однако одинаково актуальной проблемой является скорость загрузки, что ухудшается по предложению.