JavaScript style guide, JSLint, Strict Warnings
Наверное, у всех есть какой-то свой собственный стиль написания кода. Некоторое время назад мне пришлось адаптироваться к принятому в проекте стилю, который сильно отличался от моего, первое время было очень неудобно, потом привык, но не очень нравилось. В итоге выработался следующий стиль кодирования:
FD: function callee(arg) { // … } • между именем функции и открывающей скобочкой нет пробела • открывающая фигурная скобка в той же строке • закрывающая фигурная скобка на уровне function FE: var callee = function(arg) { // … }; • между function и открывающей скобочкой нет пробела Объект: var obj = { property: value, method: function(arg) { // … } }; • двоеточие не отделяется пробелом от имени свойства или метода Ветвления: if(…) { // … } else if(…) { // … } else { // … } • else/else-if yачинаются с новой строки • пробела между if и открывающей скобочкой нет Циклы: while(…) { // … } do { // … } while(…); for(…) { // … } • for только в качестве for-in Конструкторы: (new Date).getTime() • скобки функции-конструктора не ставятся, когда возможно Операторы: typeof variable if(!variable && "property" in object) {…} var a = b ? c : d; • минимум скобок • разделяются пробелами, но не отбиваются пробелами от скобок Переменные: var a = 1, b = 2, c = 3; var key, obj = {…}; for(key in obj) {…} var a; while(…) { a = i; } function(event) { event = event || window.event; var target = …; } • один var для нескольких переменных • если до этого есть var, писать еще один внутри for ни к чему • var не ставится внутри цикла (знаю, что интерпритированы они будут сразу) • var не ставится, где попало, только в начале логических блоков • существующие переменные не переопределяются с помощью var Другое: • все имена в camelStyle • для отступов используется знак табуляции • избавляемся от strict warnings в консоли Firefox • не опускаем фигурные скобки _____________________________ Только недавно догнал, что Firefox ругается только на такие функции: function() { if(…) { return …; } } а не на все функции, которые ничего не возвращают :) На некоторые вещи ругается JSLint, думаю, стоит ли следовать всем рекомендациям или это никому ненужные ограничения? Ссылки: MDC: JavaScript style guide JSLint — The JavaScript Code Quality Tool Вот, просто мысли в слух :) |
У меня так же, кроме:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
И частично: Цитата:
Цитата:
|
У нас на первом курсе в первом семестре преподаватель не принимал плохо оформленные программы. Тогда все бесились, но щас я ему очень даже благодарен -- основные принципы в подкорке мозга зашиты. Собственно отличия, как правило, у всех только где ставить открывающую фигурную скобку, отступы табуляциями или пробелами, наименование переменных и еще может что по мелочи. Поэтому некоторые пункты удивляют.
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
Цитата:
Цитата:
Цитата:
Цитата:
i++; ++j; a += -1 + k--; |
Цитата:
Цитата:
Цитата:
Цитата:
|
Цитата:
! variable ? Без пробела обычно пишу, поправил. |
Мой стиль вы все прекрасно видели:)
Никаких пробелов, минимум переноса строк и скобок... Не завидую наследнику моего кода:D Для таких ситуаций многие IDE имеют функцию форматирования. В DW для JS этого нет:( Не понимаю людей, которые вставляют пробелы и переносы везде, где можно... Окно на весь экран, а смысла никакого не видно... |
Цитата:
function foo() {...} // описание функции с именем foo(); // вызов (function() {}); // без проблела - похоже на вызов (function () {}); // а так - описание функции, исчезло только имя Вот тут давно тоже было. Что касается style-guide - это очень важная тема. Здесь приоритеты следующие (по убывающей, первые пункты - приоритет выше): 1. Style-guide принятый локально в компании. Главное - соблюдать единообразие кода. 2. Официальный Style-guide технологии. Профессиональный код (на международном уровне) должен выглядеть так. Автор технологии имеет право определять style-guide (в идеале, советуясь со сторонними мнениями и учитывая пожелания). 3. Локальная привычка. Любительский уровень, как правило используется новичками при начальном изучении. Также, может использоваться псевдо-гуру, которые хотят в этом моменте обособиться (aka, "мы не следуем за толпой и всякими там стайл-гайдами"), что является ещё большим пафосом; как правило - тоже любитель, знающий технологию ненамного глубже посредственного программера. Однако, первый пункт (с высшим приоритетом), может выбираться также конкретным человеком, исходя из своей локальной привычки и, если такой код сильно расходится с пунктом (2) - это неправильно уже. Если не задан локальный стиль в компании, то стоит придерживаться официального стиля технологии - независимо от локальных привычек. Так, например, я привык к camelCase-у в именах переменных, но, программируя на Python-e, я использую underscore_case (т.к. это рекомендация официального style-guide-а Python) - несмотря на мою привычку из ES. |
А как лучше:
if(typeof addEventListener != "undefined") {…} или if(typeof window.addEventListener != "undefined") {…} или if(window.addEventListener) {…} или if("addEventListener" in window) {…} ? Dmitry A. Soshnikov, можешь объяснить, почему и как работает такая конструкция: typeof X // "undefined" когда переменная X нигде не определена? Нормально ли так делать? |
Цитата:
|
Цитата:
typeof (11.4.3, ES-3) - это рекурсивное UnaryExpression. UnaryExpression : [...] typeof UnaryExpression [...] Т.е. можно написать так: alert(typeof typeof []); // string Также, UnaryExpression в одном из нетерминалов распадается на PostfixExpression: UnaryExpression : PostfixExpression [...] Далее, нетерминал PostfixExpression может содержать LeftHandSideExpression: PostfixExpression : LeftHandSideExpression [...] который, в свою очередь одним из нетерминалов имеет CallExpression. LeftHandSideExpression : [...] CallExpression CallExpression имеет у себя MemberExpression. CallExpression : MemberExpression Arguments [...] MemberExpression может содержать PrimaryExpression: MemberExpression : PrimaryExpression [...] А уже PrimaryExpression (наконец-то ;)) одним из своих нетерминалов имеет Identifier: PrimaryExpression : [...] Identifier [...] А дальше, работает обычное разрешение идентификаторов в Scope chain (10.1.4). И в этом случае будет возвращён объект типа Reference с базой null и именем свойства - "X". Главное здесь - база null, поскольку далее отрабатывает пункт (3) алгоритма typeof: 3. If GetBase(Result(1)) is null, return "undefined". Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
Спасибо :)
|
Цитата:
|
Начитался блин всяких style guide'ов и черновиков ECMAScript 5 :-E надо же всегда помнить про IE!
По новому стандарту ссылка arguments.callee не будет работать в "strict mode"; Решил попонтоваться и избавится он нее заранее следующим образом: (function callee() { … if (…) { setTimeout(callee, …); } }());Но у нас же есть JScript, в котором такая функция будет видна и в текущем контексте исполнения: (function callee() {}); alert(callee); Цитата:
Вот и улучшили код) |
Цитата:
var referenceToNFE = function testNFE() { alert('testNFE'); }; alert(referenceToNFE === testNFE); // false referenceToNFE.newProperty = 10; alert(testNFE.newProperty); // undefined // однако, два объекта выполняют // одинаковые действия testNFE(); // "testNFE" referenceToNFE(); // "testNFE" Подробней. |
А вот чем им, собственно, arguments.callee не угодил?
|
А чем им модель w3c не угодила Вот-вот. Её ведь в конце концов можно расширить и не превратив в модель Microsoft-а
|
Цитата:
|
Назовёте некропостером... Но спрошу: почему в javascript используется чаще всего «египетский» стиль расставления фигурных скобок? Мне кажется читаемее (ну и слово) то есть читабельнее(ещё хуже) было бы как в Java/C/C++?
И если я пишу вот эдак: function print(txt) { document.write(txt,"<br>"); }Это приемлемо? Египетская сила =) |
try { // Code } catch (e) { // Code } Так тоже читабельнее? Или так: do { // Code } while (); Имхо, код разрастается неоправдано. |
Хе-хе, тогда уж
t r y { } c a t c h ( e ) { } Я делаю так: try { //code } catch(e) { //code } do { //code } while(); if () { //code } else { //code } И сейчас меня побьют за } else { и } catch { =) Да, код растёт по вертикали. Но визуально удобнее ловить скобки, особенно если без подсветки синтаксиса работаешь. Кстати, год почти, приходилось писать скрипты на Symbian 9. И писал на небольшом экране (E63). Показалось так удобнее. Одним словом, верно ли я понимаю, что нет принятого стандарта? |
Цитата:
Цитата:
Вообще форматирование кода не так страшно, ибо во всех продвинутых IDE можно быстро отформатировать под себя. Но в этом случае растет Diff, так что в команде лучше писать в одном стиле. Цитата:
Я вот не могу читать такой код :) |
Цитата:
Цитата:
|
Цитата:
Цитата:
function fnc() { return { a : 5, b : 'string' } } alert( JSON.stringify(fnc()) ); // и чего бы Вы ожидали? |
Отличный пример! Точка с запятой втыкается после return на автомате! А ведь и правда, мог бы так написать.
Да, косяк. Похоже, необходимо переквалифицироваться в египтяне =) Цитата:
Кстати, в C# майкрософтовская визуальная среда насильно лишает листинг египетской сущности. Я сделал вывод, что египет — это неверно для любого языка. Преждевременный вывод. :dance: Ититская сила! А в Java-то египетские скобки — стандарт! http://www.oracle.com/technetwork/ja...oc-136057.html |
у меня в общих чертах схоже, но :
ставлю пробелы-границы между скобочками и тем, что туда попадает // т.е. не, if(condition){ ..... } // ,а if( condition ){ ..... } и так же с аргументами. function a( a,b,c ){} a( a,b,c ); ещё для наглядности могу не ставить запятые между аргументами, если имена переменных небольшие. иначе - ставлю a( a,b,c ); a( very_longggg, oh_yeaaah ); |
Я никогда не понимал пробелов внутри скобок. Снаружи надо отбивать, а не изнутри.
if (condition) { } |
когда есть скобки внутри condition (вызов функции проверки, z.b.), то можно запутаться, если проглядывать код, а не вчитываться.
вкусы ? |
Цитата:
|
что же, придётся переучиваться для этого? нормы есть нормы, для их соблюдения.
|
Цитата:
Ну или настроить какой-нибудь автоформаттер, запуская его перед коммитами. |
Цитата:
Цитата:
|
Цитата:
Цитата:
Есть правила, к которым все привыкли и я не вижу смысла придумывать что-то новое. |
в письменной (речи (не (употребляются (вложенные (скобки))))
|
var someVariable = "someValue", someVariable2 = "someValue", someVariable3 = "someValue"; или var someVariable = "someValue" , someVariable2 = "someValue" , someVariable3 = "someValue"; И еще if (a) b(); // Но: if(!a) { a = 5; } Как считаете, это неправильно? |
в принципе можно операторы в начало строки выносить, &&, || в этом случае легче найти, запятые... сложнее забыть указать. По поводу фигурных скобок - их лучше всегда указывать, так проще добавлять отладочные операторы. Отличие в пробелах, непонятно зачем, лучше придерживаться более распространенного варианта. Разве что можно ! отделять пробелами:
if ( ! a) {...} |
Часовой пояс GMT +3, время: 04:30. |