Красивый js код – psyrendust/js-prettify: This little beautifier will reformat and reindent bookmarklets, ugly JavaScript, unpack scripts packed by Dean Edward’s popular packer, as well as deobfuscate scripts processed by [javascriptobfuscator.com](http://javascriptobfuscator.com/).

JavaScript Code Style / Habr

Когда девять месяцев назад я написал для себя маленькую консольную утилиту, я и не подозревал, что вскоре она превратится в серьёзный и единственный в своём роде инструмент, которым будут пользоваться даже такие известные всем команды, как jQuery, Bootstrap, Angular. Сейчас, когда я пишу эту статью, у моего проекта на гитхабе 1010 звёздочек, и мне очень радостно думать о том, что так много людей смогли с помощью моей придумки сделать свою работу удобнее.

История этого проекта началась с моей личной боли.

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

Например…

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

Вот в этом-то ревью меня и поджидало разочарование.

Представьте, я целую неделю делал новую форму фидбека, отлаживал, приводил код в порядок. Но первое же замечание, которое я получил в ревью — это было: “После function нет пробела”. И точно такое же ещё в 5-ти местах кода?!

Поймите меня правильно. Я разрабатывал продукт, старался. Придумал нетривиальную логику, в которой вообще не оказалось ошибок. Но ревью я не смог пройти только потому, что забыл поставить пробел после слова «function»?! Мне это не понравилось. Мне хотелось, чтобы ревьюеры обращали внимание на мой код, на его архитектуру, на дефекты в логике, а не на нарушения командного кодстайла.

Мне стало грустно. Потом было второе подобное ревью, и повторилась та же самая ситуация с пробелом после «function». Вот дался им этот пробел! И в тот момент я отчётливо понял, что продолжаться так дальше не может. Я разозлился.

Так и родился JavaScript Code Style, — сокращенно JSCS, — инструмент, который сообщает мне обо всех нарушениях кодстайла ещё до того, как я отправляю код на ревью. Долгое время в этой утилите было лишь одно правило, которое проверяло, есть ли пробел после “function”. И этого мне было достаточно, чтобы чувствовать себя счастливым. Если мне случалось снова забыть вставить этот злосчастный пробел, JSCS мне сообщал об этом перед каждым коммитом:

Какое-то время этой утилитой пользовался я один, ни с кем не делился. А зачем? Я решил свои проблемы и успокоился. Но вскоре выяснилось, что у многих моих коллег возникают такие же проблемы с кодстайлом. Только они не пробел после “function” забывали ставить, а, например, добавить перевод строки в конце файла. Я и поделился с ними.

JSCS начал распространяться внутри Яндекса. Он стал стремительно обрастать новыми правилами. Разные команды, разные кодстайлы — стали появляться новые интересные правила, например, запрет на неявное приведение типов (!!x — плохо, Boolean(x) — хорошо). А немного погодя, я выложил JSCS на гитхаб. И тогда правила стали добавляться и внешними (относительно Яндекса) людьми. И вдруг посыпались звёздочки.

Если спросить меня, что вызвало такой взрывной рост популярности этого проекта, я отвечу.

В первую очередь, подобного полноценного инструмента не существовало в тот момент, и я не уверен, что есть сейчас. Вторая причина заключается в том, что инструмент призван решить одну маленькую, всем понятную, актуальную для многих, задачу. И третья, на мой взгляд, очень важная причина — я смог сделать инструмент с простой и очевидной программной архитектурой. То есть, инструмент не пытается решать кучу разноплановых задач, он делает что-то одно, но делает это очень хорошо.

Почему не стали расширять jshint, ведь раньше jshint имел ряд правил по проверке стилистики кода?

Эти правила были неполны, хаотичны, и сами разработчики jshint’а хотели от них избавиться. Вот почему в репозитории JSCS появился появился тикет №102 где Майк (Mike Sherov) начал переносить правила проверки стиля из jshint в jscs. Сейчас в новой версии jshint’а нет ни одного правила проверки стилистики, и JSCS стал единственным полноценным инструментом, который решает эту задачу.

А ещё у проекта появилось еще два постоянных мейнтейнера. Ими оказались ребята, которые занимаются разработкой ядра jQuery – Mike Sherov (mikesherov) и Олег Гайдаренко (markelog), они разгребают огромное количество тикетов, которые приходят от пользователей. И те звездочки, которые заработал проект на гитхабе, их большая заслуга. Спасибо вам, ребята, большое!

Страница проекта на гитхабе: https://github.com/mdevils/node-jscs. На этой страницы описано более 60-ти правил, с помощью которых можно настроить валидацию кодстайла в проекте.

Приходите, пользуйтесь, вдруг и вам тоже понравится.

Оформление кода, оптимизация процесса проверки качества кода / Habr

JavaScript, the winning style

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

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

В отличие от Питона у которого есть единый свод правил «Style Guide for Python Code», у языка JavaScript такого нет. Однако на выбор есть целых 6 популярных гайдов:

Помимо гайдов, не стоит так же забывать об автоматических анализаторах кода, таких, например, как JSLint и JSHint. И в них уже заложены свои настройки. Вопрос в том, какой же все-таки максимально правильный способ писать код на JavaScript, который был бы актуален и максимально соответствовал бы большинству рекомендаций?

Давайте попробуем объединить большинство рекомендаций в этой статье и подумаем как можно оптимизировать процесс проверки качества кода.

Оформление

Отступ

• 2 пробела, не больше и без табуляции: Google, npm, Node.js, Idiomatic
• Табуляция: jQuery
• 4 пробела: Crockford

Пробел между аргументами и выражением

• Без пробела, как на примере: Google, npm, Node.js

  project.MyClass = function(arg1, arg2) {
  

  
  
• С пробелом, как на примере: Idiomatic, jQuery

  for ( i = 0; i < length; i++ ) {
  

  
  
• Без особого мнения: Crockford

Многие гайды так же напоминают, чтобы не было пробелов в конце строк (trailing spaces)

Длина строки

• Максимум 80 знаков: Google, npm, Node.js, Crockford

  При переносе строк, отступ не обязательно должен быть равен 2, если вам надо, например, перенести на следующую строку аргументы функции, то выровнить их можно по тому месте где стоит первый аргумент. Как другой вариант, можно так же использовать 4 пробела вместо 2, когда переносите длинные строки.
• Без особого мнения: jQuery, Idiomatic

Точка с запятой

• Всегда использовать точку с запятой: Google, Node.js, Crockford
• Не использовать в некоторых ситуациях: npm
• Без особого мнения: jQuery, Idiomatic

Комментарии:

• JSDoc: Google, Idiomatic
• В Idiomatic Style Guide так же разрешены более простые комментарии, но JSDoc предпочтительнее
• Без особого мнения: npm, Node.js, jQuery, Crockford

Кавычки

• Предпочтительнее одинарные кавычки. Лучше 'value', чем "value": Google, Node.js
• Двойные кавычки «: jQuery
• Без особого мнения: npm, Idiomatic, Crockford

Декларирование переменных

• Одна переменная на одной строке: Node.js

  var foo = '';
  var bar = '';
  

  
  
• Несколько переменных, разделяемые запятыми в конце строки, как на примере: Idiomatic, jQuery

  var foo = "",
     bar = "",
     quux;
  

  
  
• Запятая в начале строки: npm

  var foo = ""
    , bar = ""
    , quux;
  

  
  
• Без особого мнения: Google, Crockford

Скобки

Глобальные переменные

• Не используйте глобальные переменные: Google, Crockford

  Google:
  

  Global name conflicts are difficult to debug, and can cause intractable problems when two projects try to integrate. In order to make it possible to share common JavaScript code, we’ve adopted conventions to prevent collisions.

  
  Перевод:
  

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

• Crockford считает, что глобальные переменные не нужно использовать вовсе.
• Без особого мнения: Idiomatic, jQuery, npm, Node

Имена

Переменные

Константы

Функции

• Первое слово с маленькой буквы, все последующие с большой (camelCaps/camelCase): Google, npm, Node, Idiomatic

  Предпочтительнее длинное имя, которое бы описывало действие функции

  function veryLongOperationName
  function short()..
  

  Используйте слова is, set, get:

  function isReady()
  function setName()
  function getName()
  

  
  
• Без особого мнения: jQuery, Crockford

Массивы

• Используйте множественную форму слова: Idiomatic

   var documents = [];
  

  
  
• Без особого мнения:Google, jQuery, npm, Node, Crockford

Объекты и классы

Другое

Используйте all-lower-hyphen-css-case для многосоставных названий файлов и настроек: npm

Используйте JSHint и .jshintrc файл

JSHint — это анализатор кода, который укажет вам на ошибки в коде. Он совместим со многими широко используемыми текстовыми редакторами. Так же это хороший способ поддерживать стилистическое единство и целостность кода. Различные способы использования можно найти в документации. Ниже наш пример .jshintrc файла, который следует всем данным выше рекомендациям. Поместите этот файл а корневую папку вашего проекта, и если у вас установлен JSHint плагин, то ваш редактор теперь будут проверять код в соответствии с правилами которые вы определили.

{
  "camelcase" : true,
  "indent": 2,
  "undef": true,
  "quotmark": "single",
  "maxlen": 80,
  "trailing": true,
  "curly": true
}

Во все файлы, которые обрабатываются браузером добавляем:

/* jshint browser:true, jquery:true */

В файлы Node.js добавляем:

/*jshint node:true */

Во все типы JS файлов, так же лучше добавить:

'use strict';

Это повлияет и на JSHint и на обработчика JavaScript в целом, который станет менее терпимым к ошибкам, но будет работать быстрее. Почитать больше о ‘use strict’ (внешняя ссылка)

Автоматическая проверка кода JSHint перед git commit

Если вы хотите быть уверены в том что все ваши JS файлы прошли проверку и следуют общему стилю, который вы определили в .jshintrc. То добавьте эти строки в ваш .git/hooks/pre-commit файл. Теперь перед тем как закомитить изменения, скрипт будет проверять только измененные файлы на нарушения стилистики кода. И если таковые имеются, то операция будет прервана.

#!/bin/bash
# Pre-commit Git hook to run JSHint on JavaScript files.
#
# If you absolutely must commit without testing,
# use: git commit --no-verify

filenames=($(git diff --cached --name-only HEAD))

which jshint &> /dev/null
if [ $? -ne 0 ];
then
  echo "error: jshint not found"
  echo "install with: sudo npm install -g jshint"
  exit 1
fi

for i in "${filenames[@]}"
do
	if [[ $i =~ \.js$ ]];
	then
		echo jshint $i
		jshint $i
		if [ $? -ne 0 ];
		then
			exit 1
		fi
	fi
done
 
 

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

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

Оригинальная статья: (http://seravo.fi/2013/javascript-the-winning-style)

7 рекомендаций по оформлению кода на JavaScript / Блог компании RUVDS.com / Хабр

Автор материала, перевод которого мы публикуем сегодня, говорит, что она прямо-таки одержима написанием чистого кода. Она считает, что код надо писать так, чтобы, во-первых, с ним, в будущем, удобно было бы работать другим программистам, включая его автора, а во-вторых — с учётом возможности расширения этого кода. То есть, нужно стремиться к тому, чтобы в приложение сравнительно просто было бы добавлять новые возможности, и чтобы его кодовую базу было бы удобно сопровождать. Если бы программы писали, учитывая лишь нужды компьютеров, то, вероятно, программисты могли бы выражать свои мысли лишь с помощью нулей и единиц, больше ни о чём не заботясь. В этой статье приводится ряд рекомендаций по написанию качественного кода, проиллюстрированных примерами на JavaScript.

1. Используйте понятные имена переменных и функций

Код гораздо легче читать, когда при его написании используют понятные, описательные имена функций и переменных. Вот не очень понятный код:

function avg (a) {
  let s = a.reduce((x, y) => x + y)
  return s / a.length
}
 

Его читабельность значительно улучшится, если использовать в нём понятные имена переменных и функций, отражающие их смысл.

function averageArray (array) {
  let sum = array.reduce((number, currentSum) => number + currentSum)
  return sum / array.length
}

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

2. Пишите короткие функции, решающие одну задачу

Функции легче поддерживать, они становятся гораздо более понятными, читабельными, если они направлены на решение лишь какой-то одной задачи. Если мы сталкиваемся с ошибкой, то, при использовании маленьких функций, найти источник этой ошибки становится гораздо легче. Кроме того, улучшаются возможности по повторному использованию кода. Например, вышеприведённой функции можно было бы дать имя sumAndAverageArray, так как в ней мы вычисляем сумму значений элементов массива, используя метод reduce, а затем находим среднее значение, деля полученную сумму на количество элементов массива. Вот эта функция.

function sumAndAverageArray(array) {
  let sum = array.reduce((number, currentSum) => number + currentSum)
  return sum / array.length
}

Её можно разбить на две функции, тогда роль каждого фрагмента кода станет более понятной. Кроме того, если мы создаём большую программу, наличие функции sumArray может оказаться очень кстати. Вот код двух новых функций. Одна вычисляет сумму элементов массива, вторая возвращает их среднее значение.

function sumArray(array) {
  return array.reduce((number, currentSum) => number + currentSum)
}

function averageArray(array) {
  return sumArray(array) / array.length
}

Признаком того, что функцию можно разбить на две, является возможность использования слова «and» в её имени.

3. Документируйте код

Пишите хорошую документацию к своему коду — тогда тот, кто столкнётся с ним в будущем, поймёт, что и почему в этом коде делается. Вот пример неудачной функции. Здесь используются некие «магические числа», их смысл нигде не пояснён.

function areaOfCircle (radius) {
  return 3.14 * radius ** 2
}

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

const PI = 3.14 // Число Пи, округлённое до двух знаков после запятой

function areaOfCircle (radius) {
  // Функция реализует математическую формулу вычисления площади круга:
  // Число Пи умножается на квадрат радиуса круга
  return PI * radius ** 2
}

Этот код — всего лишь пример. Вероятно, в подобной ситуации, вместо введения собственной константы, хранящей число Пи, лучше будет воспользоваться стандартным свойством Math.PI.

Комментарии к коду должны отвечать на вопрос «почему».

Обратите внимание на то, что для целей документирования кода имеет смысл воспользоваться специальными инструментами и соответствующими им правилами комментирования кода. В применении к Python мне нравится Google Style Docstrings, в применении к JavaScript — JSDoc.

4. Подумайте об использований правил Сэнди Метц

Сэнди Метц отлично программирует на Ruby, делает интересные доклады и пишет книги. Она сформулировала четыре правила написания чистого кода в объектно-ориентированных языках. Вот они.

1. Классы не должны быть длиннее 100 строк кода.
2. Методы и функции не должны быть длиннее 5 строк кода.
3. Методам следует передавать не более 4 параметров.
4. Контроллеры могут инициализировать лишь один объект.

Рекомендую посмотреть её выступление, касающееся этих правил.

Я следую этим правилам уже примерно два года, и они так основательно закрепились в моём сознании, что я выполняю их, буквально, «на автомате». Мне они нравятся, и я полагаю, что благодаря их использованию повышается удобство сопровождения кода.

Обратите внимание на то, что данные правила — это лишь рекомендации, но их использование позволит сделать ваш код значительно лучше.

5. Применяйте выбранные правила последовательно

Последовательное применение правил написания кода очень важно независимо от того, пишете ли вы код некоего проекта самостоятельно или работаете в команде. В частности, выражается это в том, что тот, кто читает код, являющийся результатом командной разработки, должен воспринимать его как единое целое. При таком подходе авторство отдельных строк кода можно установить, лишь обратившись к Git. Если вы, в JavaScript, используете точку с запятой — ставьте её везде, где это нужно. То же самое касается и кавычек — выберите двойные или одинарные кавычки и, если на то нет веских причин, всегда используйте то, что выбрали.

Рекомендую применять руководство по стилю кода и линтер, который позволяет приводить код к выбранному стандарту. Например, мне, для JavaScript, нравятся правила Standard JS, для Python — правила PEP8.

На самом деле, главное здесь — найти правила оформления кода и их придерживаться.

6. Помните о принципе DRY

Одна из первых идей, которую стараются донести до того, кто хочет стать программистом, звучит так: «не повторяйся» (Don’t Repeat Yourself, DRY). Если вы замечаете в своих проектах повторяющиеся фрагменты — используйте такие программные конструкции, которые позволят сократить повторы одного и того же кода. Я часто советую моим ученикам поиграть в игру SET для того, чтобы улучшить их навыки по распознаванию шаблонов.

Однако если вы приметесь фанатично применять принцип DRY или решите абстрагировать неудачно выбранные шаблоны, читаемость кода может серьёзно ухудшиться, и, позже, вам может понадобиться чаще прибегать к созданию копий одних и тех же конструкций. У Сэнди Метц, кстати, есть отличная статья, посвящённая тому, что дублирование кода — это меньшее зло, нежели неудачная абстракция.

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

7. Используйте идеи инкапсуляции и модульности

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

let name = 'Ali'
let age = 24
let job = 'Software Engineer'

let getBio = (name, age, job) => `${name} is a ${age} year-old ${job}`

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

class Person {
  constructor (name, age, job) {
    this.name = name
    this.age = age
    this.job = job
  }

  getBio () {
    return `${this.name} is a ${this.age} year-old ${this.job}` 
  }
}

А если в программе надо работать лишь с данными об одном человеке, то их можно оформить так, как показано ниже.

const ali = {
  name: 'Ali',
  age: 24,
  job: 'Software Engineer',
  getBio: function () {
    return `${this.name} is a ${this.age} year-old ${this.job}` 
  }
}

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

Итоги

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

Уважаемые читатели! Каких правил оформления кода придерживаетесь вы?

Игра в 0 строк кода на чистом JS / Habr

Я не хотел принимать участие в недельном тренде хабра — «Все пишем в 30 строк кода!», нет времени лишнего. Но пост theaqua про Hello world в 1 строчку на чистом JavaScript вдохновил меня побить этот рекорд. Я написал игру, используя JavaScript, HTML и CSS, при этом использовал всего 0 строк кода. После этого поста я не мог спать. Я мучался бессоницей и, взяв себя в руки, сел писать игру. Понимая что мне придется использовать 0 строк кода на Javascript — я сильно боялся. Написать программу в 1000 строк кода и больше — не составляет проблем. Но вот написать 0 строк кода… Это безумие. Это переворачивает мозг. Меняет отношение к вебу. Понимаешь, что раньше ты писал как-то не так…

Для тех, кто не привык ждать — ДЕМКА.

Это не фейк, а полноценная игра. Подробности под катом.

Требования

Браузеры: Chrome, FF, Safari, IE10+

Как играть

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

Для наглядности есть видеотуториал:

Постскриптум

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

Раньше я снисходительно относился к HTML-программистам. Но теперь я понял, что скоро они могут завоевать мир. Вы вспомните как когда-то JS программистов не воспринимали всерьез. Помните эти темные времена? А сейчас оглянитесь… JavaScript — это не просто тренд. Он уже везде. В браузерах, на сервере, в микроконтроллерах, мобильных ОС… На нем пишут ОС, игры… И вот тихо подкрадываются к нам HTML-программисты.

Однажды писать 0 строк кода на JS cтанет нормой. JS будет таким же немодным как сейчас Flash. Зачем писать на JS, если он работает медленнее чем HTML программа, написанная HTML программистом с использованием CSS.

UPD:
Репозиторий:
github.com/i0z/nojsgame

Фидлы:
jsfiddle.net/9dQx3/10
codepen.io/i0z/pen/mFLCw

Оригинал nojsgame.majorov.su