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, время: 07:07. |