Предисловие:
Стиль кодирования языка программирования очень важен для долгосрочного программного обеспечения для обслуживания, особенно в командной работе. Если команда использует унифицированный и стандартизированный стиль кодирования, она может улучшить уровень сотрудничества команды и эффективность работы. В основе руководства по стилю программирования лежат основные правила форматирования, которые определяют, как писать код высокого уровня. Это руководство поступает из книги «Написание обслуживания JavaScript», основанную на «спецификациях кодирования языка Java» и спецификациях программирования JavaScript Crockford, а также некоторых личных и предпочтений Никболаса. Целью написания этой статьи является углубление вашего впечатления и заставить больше людей понять стиль кодирования JS и улучшить качество их кодирования. Для получения дополнительной информации, пожалуйста, прочитайте «Написание обслуживания JavaScript».
1. Подтверждение
Уровень каждой строки состоит из 4 пространств, избегая вкладки с использованием вкладки.
// Хороший метод написания if (true) {dosomething ();}2. Длина строки
Каждая строка не должна превышать 80 символов в длину. Если линия превышает 80 символов, она должна быть сломана после оператора. Следующая строка должна добавить два уровня отступления (8 символов).
// Хороший метод письма dosomething (Argent1, Argent2, Aegment3, Argement4, Argement5); // Плохое написание метод: отступает что -то (аргумент1, аргумент2, aegment3, argement4, аргумент5);
3. исходное значение
Строки всегда должны использовать двойные кавычки и сохранять одну строку, избегая использования чертов, чтобы запустить одну строку в строке.
Числа должны использовать десятичные целые числа, а научные алгоритмы представляют целые числа, шестнадцатеричные целые числа или десятичные десятичные десятичные значения. По крайней мере, одно число должно быть сохранено до и после десятичного десятичного. Избегайте использования восьми прямых величин.
Следует избегать специальной стоимости NULL, кроме как в следующих случаях.
• Используется для инициализации переменной, которая может быть назначена значением объекту.
• Используется для сравнения с инициализированной переменной, которая может быть или не является объектом.
• Когда ожидается, что параметр функции будет объектом, он передается как параметр.
• Когда ожидается возвращаемое значение функции, оно будет издано как возвратное значение.
Избегайте использования специальных значений, неопределенных. Чтобы определить, определена ли переменная, следует использовать оператор типа.
4. Расходы операторов
Пространство должно использоваться до и после бинарного бюджета, чтобы сохранить выражение аккуратным. Операторы включают операторов назначения и логические операторы.
// хорошее письмо для (var i = 0; i <count; i ++) {process (i);} // Плохое письмо: потерянное пространство для (var i = 0; i <count; i ++) {process (i);}5. Интервал кронштейнов
При использовании кронштейнов не должно быть места сразу после левого кронштейна и непосредственно перед закрытым кронштейном.
// хорошее письмо для (var i = 0; i <count; i ++) {process (i);} // Плохое письмо: на обеих сторонах параметра есть дополнительные места для (var i = 0; i <count; i ++) {i);}6. Прямое измерение объекта
Прямое количество объекта должно иметь следующий формат.
• Начальные левые скобки должны храниться на той же линии, что и выражение.
• Значение имени каждого атрибута должно соблюдать отступ, а первым атрибутом должен быть новая строка после левой кудрявой скобки.
• Значение имени каждого атрибута следует использовать без кавычек, за которым следует толстая кишка (до пространства), за которым следует значение.
• Если значение атрибута является типом функции, корпус функции должен запустить новую строку под именем атрибута, а пустая строка должна быть сохранена до и после нее.
• Пустые строки могут быть вставлены до и после набора связанных свойств для улучшения читаемости кода.
• Конечная правая скобка должна занимать исключительно одну линию.
// Хороший метод написания var object = {key1: value1, key2: value2, func: function () {// dosomething}, key3: value3}; // Плохое написание метод: неподходящее отступление var obj // dosomething}, key3: value3};Когда буквальный объект используется в качестве параметра функции, если значение является переменной, начальные скобки должны быть на той же строке, что и имя функции. Все остальные ранее перечисленные правила также применяются.
// Хороший метод письма dosomething ({key1: value1, key2: value2}); // Метод плохого написания: все коды dosomething ({key1: value1, key2: value2});7. Комментарии
Использование кратких и четких комментариев может помочь другим понять ваш код. Комментарии должны использоваться в следующих ситуациях.
• Код неясен.
• Коды, которые могут быть приняты за ошибку.
• Необходимый, но не очевидный код, специфичный для браузера.
• Для объектов, методов или свойств необходимо генерировать документы (используя соответствующие комментарии документа).
Комментарии с одной строкой
Однострочные комментарии должны использоваться для иллюстрации одной строки кода или набора связанных кодов. Там может быть три способа использовать однострочные комментарии.
• Эксклюзивные комментарии, чтобы объяснить следующую строку кода.
• Комментарии в конце строки кода, чтобы объяснить код перед ним.
• Несколько строк, чтобы прокомментировать блок кода.
// Хорошее написание if (условие) {// Если код выполнен здесь, это означает, что все проверки безопасности были проведены;} // Плохое письмо: нет пустой строки перед комментарием, если (условие) {// Если код здесь выполняется, это означает, что все проверки безопасности были проходят; Написание: следует использовать многострочные комментарии // Этот фрагмент кода используется для ** суждения // Тогда if (условие) {// Если код выполняется здесь, это означает, что все проверки безопасности были проведены;} // Хорошее написание: при комментировании в конце строки необходимо соблюдать пространство между концом кода и комментарием, если (условие) {// если код выполняется здесь, это означает, что это означает, что это означает, что все это означает, что все это означает, что это означает, что это было продлено). // Выполнить функцию ** // Плохое письмо: между кодом и комментария и комментария if (условие) {// Если код здесь выполняется, это означает, что все проверки безопасности были проведены разрешено (); // Выполнить функцию ** // Хорошее написание: при комментировании кодового блока вам следует связаться, чтобы использовать комментарий одной строки, и в этом случае не следует использовать многострочные комментарии. // if (условие) {// Alting (); // выполнить ** функция //}Многострочные комментарии
Многослойные комментарии должны использоваться, когда код нуждается в большем количестве текста для интерпретации. Каждый многострочный комментарий имеет как минимум три строки следующим образом:
1. Первая строка включает только начало комментариев /*. В этой строке не должно быть другого текста.
2. Следующие строки начинаются с * и остаются выровненными. Они могут быть описаны словами.
3. Последняя строка начинается с */ и остается выровненной с предыдущей строкой. Там не должно быть другого текста.
Первая строка многострочного комментария должна поддерживать тот же уровень отступления, что и код. Каждая последующая строка должна иметь одинаковый уровень вдавливания и подключенное пространство (чтобы правильно держать * символы выровненными). Пустая строка должна быть зарезервирована перед каждым многострочным кодом.
// Хороший метод написания, if (условие) {/** Если код выполнен здесь* это означает, что все обнаружения безопасности были переданы*/ Apply ();}Заявление о комментарии
Комментарии иногда можно использовать для объявления дополнительной информации в кусок кода. Формат этих утверждений начинается с одного слова и сразу же следует толстой кишкой. Заявления, которые можно использовать, следующие.
TODO: Код описания еще не завершен. Это должно включать то, что вы хотите сделать дальше.
Hack: Это показывает, что реализация кода взяла ярлык. Следует включать причины, почему взломы используются. Это также может указывать на то, что может быть лучшее решение проблемы.
XXX: Объясните, что код проблематичен и должен быть исправлен как можно скорее.
FixMe: Объясните, что код проблематичен и должен быть исправлен как можно скорее. Это немного второе место в XXX.
Обзор: Коды инструкций должны быть рассмотрены в любых возможных изменениях.
Эти объявления могут использоваться в одном или нескольких комментариях и должны следовать тем же правилам форматирования, что и общий тип комментариев.
8. Наименование
Переменные и функции должны быть осторожны при их именовании. Наименование должно быть ограничено численными алфавитными символами, и в некоторых случаях можно использовать подчеркивание (_). Лучше всего не использовать знак доллара ($) или Backslash (/) в любом именовании.
Переменное именование должно быть в формате именования верблюда, с первой буквой нижней части и первой буквой каждого слова прописного. Первым словом имени переменной должно быть существительное (не глагол), чтобы избежать путаницы с той же функцией. Не используйте подчеркивание в именах переменных.
// Хороший метод написания var account = "test001"; // Метод плохого написания: начните с заглавных букв var accountnumber = "test001"; // Метод плохого написания: начните с глагола var getAccountnumber = "test001"; // Метод плохого написания: используйте подчеркивание var account_number = "test001";
Имена функций также должны быть в формате именования верблюда. Первым словом имени функции должно быть глагол (не существительное), чтобы избежать путаницы с той же переменной. Лучше всего не использовать подчеркивание в именах функций.
// Хорошая функция метода записи dosomething () {// code} // Метод плохого написания: function dosomething () {// code} // Метод плохого написания: function something () {// code} // Метод плохого написания: используйте функцию подчеркивания do_something () {// code}Конструктор - функция, которая создает новый объект через новый оператор - также должна быть названа в формате верблюда, а первый символ заглавляется. Имя конструктора должно начинаться с неверного, потому что новое представляет операцию создания экземпляра объекта.
// Хорошая функция метода записи myObject () {// code} // Метод плохого написания: function myObject () в начале строчных букв {// code} // Метод плохого написания: используйте функцию подчеркивания my_object () {// code} // Плохое метод написания: функция в начале глагола getMyObject () {// codИмя констант (переменные, значения которых не изменены) должно быть заглавным буквами, разделенными одним подчеркиванием между разными словами.
// Хороший метод написания var total_count = 10; // Метод плохого написания: Форма верблюда var totalCount = 10; // Плохое написание метод: смешанная форма var total_count = 10;
Атрибуты объектов такие же, как и у переменных. Методы объектов такие же, как и в функциях. Если имущество или метод является частным, перед ним следует добавить подчеркивание.
// Хороший метод написания var object = {_count: 10,4 _getCount: function () {return this._count; }}9. Объявления переменных и функций
Переменная объявление
Все переменные должны быть определены заранее перед использованием. Определения переменных должны быть размещены в начале функции, используя выражение var, одну переменную на линию. За исключением первой строки, все ряды должны быть отступают еще один слой, чтобы имена переменных могли быть выровнены вертикально. Определения переменных должны быть инициализированы, и операторы назначения должны поддерживать последовательное отступление. Инициализированная переменная должна быть до того, как переменная будет инициализирована.
// Хороший метод написания var count = 10, name = "jeri", sud = false, пусто;
Функциональное объявление
Функции должны быть определены заранее перед использованием. Функция, которая не является методом (то есть без атрибута как объекта), должна использовать формат, определяемый функцией (не в формате экспрессии и функции функции). Там не должно быть места между именем функции и стартовыми скобками. Место должно быть оставлено между финальными кронштейнами и вьющимися кронштейнами справа. Кудрявые брекеты справа должны оставаться на той же строке, что и ключевое слово функции. Там не должно быть места между начальными и конечными кронштейнами. Пространство должно быть оставлено после запятой между именами параметров. Функциональный корпус должен оставаться с отступом на первом уровне.
// Хорошая функция написания функции Outter () {var count = 10, name = "jeri", sud = false, пусто; Функция inner () {// code} // код, который вызывает inner ()}Анонимные функции могут быть назначены как методы объектам или в качестве параметров для других функций. Не должно быть места между ключевым словом функции и стартовым кронштейном.
// Хороший метод записи object.method = function () {// code}; // Плохое написание метод: неверный пространство object.method = function () {// code};Непосредственно вызванная функция должна быть завернута в садовые кронштейны на внешнем слое функционального вызова.
// Хороший метод var value = (function () {// корпус функции return {message: "hi"}} ());Строгий режим
Строгий режим должен использоваться только в функциях и не должен использоваться во всем мире.
// Метод плохого написания: используйте строгий режим «Использовать строгое»; function dosomething () {// code} // Хороший метод написания функции dosomething () {"Использовать strict"; // код}10. Операторы
Назначение
При назначении значения переменной, если правая сторона является выражением, содержащим оператор сравнения, его необходимо обернуть в скобки.
// хорошее написание var flag = (i <count); // Плохое письмо: отсутствующие скобки var flag = i <count;
Оператор равных знаков
Используйте === (строго равное) и! == (Строго неравенно) вместо == (равно) и!
// хорошее написание var одинаково = (a === b); // хорошее написание var some = (a == b);
Тройной оператор
Тройной оператор следует использовать только в условных операторах назначения и не должен использоваться в качестве замены операторов IF.
// Хороший метод написания var value = условие? Значение1: value2; // Метод плохого написания: без назначения, если выражение следует использовать? dosomething (): dosomethingelse;
11. Заявление
Простое заявление
Каждая строка содержит только одно утверждение больше всего. Все простые утверждения должны заканчиваться полуколоном (;).
// Хороший метод письма count ++; a = b; // Метод плохого написания: несколько выражений записываются в одну строк Count ++; a = b;
ОТВЕТСТВЕННОЕ ОТПРАВЛЕНИЕ
Ответные операторы не должны быть завернуты в скобки при возврате значения, если в некоторых случаях это не может облегчить возвращаемое значение для понимания. Например:
return; return collection.size (); return (размер> 0? Размер: defaultize);
Составные заявления
Составной оператор - это список утверждений, заключенных в брекеты.
• Прилагаемое утверждение должно быть отступок на один уровень больше, чем составной оператор.
• Начальные скобки должны быть в конце линии, где расположено составное утверждение; Конечные скобки должны занимать одну линию и оставаться отступами так же, как начало составного оператора.
• Когда утверждение является частью структуры управления, например, если или для операторов, все операторы должны быть заключены в скобки, включая один оператор. Эта конвенция облегчает нам добавление заявлений, не беспокоясь о том, чтобы забыть добавить кронштейны и вызвать ошибки.
• Ключевые слова для утверждения, например, если следует запустить, с последующим пространством, и запускаемые скобки должны сопровождаться пространством.
Если утверждение
Оператор IF должен быть в следующем формате.
if (условие) {операторы} if (условие) {операторы} else {операторы} if (условие) {утверждения} else if (condition) {antivements} else {antivements}Никогда не разрешается опускать кудрявые скобки в операторах IF.
// хорошее написание if (condity) {dosomething ();} // Плохое письмо: Невыполненные пространства if (condity) {dosomething ();} // Плохое письмо: весь код находится на одной строке, если (условие) {dosomething (); } // Плохое письмо: весь код находится на одной строке, и нет вьющихся скобок, если (условие) dosomething ();для заявления
Для типовых операторов должны быть в следующем формате.
for (инициализация; условие; обновление) {операторы} для (переменная в объекте) {операторы}Часть инициализации оператора не должна иметь переменных объявлений.
// Хороший метод var i, len; for (i = 0, len = 0; i <len; i ++) {// code} // Плохое написание: объявить переменную для (var i = 0, len = 0; i <len; i ++) {// код} // Плохое письмо: ДЕКАРИТЬ ВЕРИЯ ДЛЯ (VAR PROP в объекте) {// код}}}}}При использовании оператора For-In, не забудьте использовать hasownproperty () для двойной проверки для фильтрации членов объекта.
в то время как заявление
Заявления класса Whole должны быть в следующем формате.
while (условие) {операторы}делать заявление
Заявления класса DO должны быть в следующем формате.
DO {операторы} while (условие);оператор переключения
Заявления класса Switch должны быть в следующем формате.
Switch (Expression) {Case Expression: операторы по умолчанию: операторы}Первый случай под переключателем должен соблюдать отступ. Каждый случай, кроме первого, включая дефолт, должен держать пустую линию перед ним.
Каждый набор операторов (кроме по умолчанию) должен заканчиваться перерывом, возвратом, бросью или пропусканием с линией комментариев.
// Хороший переключатель метода записи (значение) {case 1:/ * пропадает через */ case 2: dosomething (); перерыв; Случай 3: вернуть True; по умолчанию: бросьте новую ошибку («Некоторая ошибка»);}Если оператор переключения не содержит случая по умолчанию, должна быть заменена линия комментариев.
// Хороший переключатель метода записи (значение) {case 1:/ * пропадает через */ case 2: dosomething (); перерыв; Случай 3: вернуть True; по умолчанию: // Нет по умолчанию}попробуйте заявление
Заявления класса TRY должны быть отформатированы следующим образом.
try {antagements} catch (variable) {antagements} try {antagements} catch (variable) {anticents} наконец {операторы}12. Оставьте белый
Добавление пустых строк кода между логическим кодом может улучшить читаемость кода.
Две пустые линии ограничены для использования в следующих ситуациях:
• Между различными файлами исходного кода.
• Между определениями класса и интерфейса.
Одностроительные пустые линии доступны только в следующих случаях.
• Между методами.
• Между локальной переменной в методе и оператором первой строки.
• Перед несколькими комментариями или единой строкой.
• Логические блоки кода в методе используются для улучшения читаемости кода.
Пространства следует использовать в следующих ситуациях.
• Случай, когда ключевые слова следуют скобки, должны быть разделены пространствами.
• Пространство должно быть оставлено после запятой в списке параметров.
• Операнды всех бинарных операторов, за исключением точек (.), Должны быть разделены пространствами. Операторы операторов монологов не должны быть разделены пробелами, такими как Unary Minus Sign, Increment (++), уменьшение (-).
• Выражения утверждения для получения должны быть разделены пространствами.
13. чего нужно избежать
• Не создавайте новые объекты, используя исходные типы обертки, такие как String.
• Избегайте использования eval ().
• Избегайте использования с операторами. Это утверждение больше не существует в строгом режиме, а также может быть удалено в будущих стандартах ECMASCRIPT.
Написано в конце
Вышеуказанные направляющие не выполняются полностью в процессе разработки. Мы можем только нарисовать некоторые из них, чтобы улучшить наш стиль кодирования и сделать наш код читаемым и поддержанным. Что касается стиля кодирования, у каждой команды есть свои характеристики. Пока команда является последовательной, можно эффективно развиваться. Некоторые правила - это не то, что мы должны постоянно подчиняться. Например, с точки зрения отступа, мы часто используем ключ вкладки более удобной, но мы не можем гарантировать, что вкладка представляет 4 места в любой среде. Чтобы поддерживать согласованность в отступе, если используется ключ вкладки, он должен использоваться на протяжении всего процесса; И нам также не нужно использовать «» и «», и это также возможно использовать », если вы сохраняете постоянный стиль. Есть много других подобных проблем стиля, и все это на основе личного выбора.
Там нет абсолютных правил, только подходящих или нет.