Comments 64
Ммм… Потому что могут?
Спасибо, не надо.
<div
className="HelloWorld"
title={`You are visitor number ${num}`}
onMouseOver={onMouseOver}
>
(из официального примера)
Единственное, что меня смущает в а автоматических форматтерах — то, что они не могут распознавать случаи, когда программист сам выставляет пробелы для форматирования. Они их убирают и код наоборот становится нечитаемым.
Для таких случаев можно поставить коммент prettier-ignore. Prettier оставит форматирование этого куска как и было:
// prettier-ignore
matrix(
1, 0, 0,
0, 1, 0,
0, 0, 1
);
Возможно, и у JavaScript появиться свой евангелист…
Кода вижу что-то вроде этого:
function getTotalPrice(sum){
var price=sum || 0,
tax = 5;
price+= tax;
var delivery = 3;
if(price<10) price += delivery;
return price;
}
Не могу удержаться и не переписать с «правильными» пробелами, скобками и тд:
function getTotalPrice(sum) {
var price=sum || 0,
tax = 5,
delivery = 3;
price += tax;
if (price < 10) {
price += delivery;
}
return price;
}
Есть главы в книгах Стефанова «JavaScript. Шаблоны » и у Крокфорда «JavaScript. Сильные стороны»(где он про JSLint пишет) рекомендации как оформлять код.
Было бы лучше, так:
function getTotalPrice(sum) {
var price = sum || 0,
tax = 5,
delivery = 3;
price += tax;
if (price < 10) {
price += delivery;
}
return price;
}
нечего даже обсуждать — у Prettier’а несколько опций;
Это не совсем правда. Опций немного, но они очень холивароспособствующие.
Есть опции для отступов табами вместо пробелов, установки точек с запятой или нет, одинарных кавычек вместо двойных. Пространство для холивара имеется, пусть и не такое большое, как при настройке Eslint.
Про development standards никогда не слышали? Простой документ с элементарным набором правил по разработке (включающий, но не ограниченный, naming conventions и тем самым форматированием), который почетно вручается каждому программеру, пришедшему на проект/в компанию. Тому, кто не блюдет — по шапке. Проблемы?
Все это происходит по той же причине, по которой некоторые "работники" на рабочем месте проводят меньше времени, чем возле кофе-машины и в курилке — видимо заниматься ерундой гораздо важнее, чем совместно добиваться успешного выполнения поставленной задачи. И это уже проблема не отдельно взятого техлида, а менеджмента проекта, а то и компании в целом. Рыба гниет с головы и о корпоративной культуре недаром написаны книги. Если подобные вещи Вам не кажутся очевидными, то этот разговор окончен — мне Ваш опыт, как представителя по-видимому низшей лиги, неинтересен.
Например вот сейчас в Питоне можно написать
def f(a, b, c):
pass
а можно
def f(a,
b,
c):
pass
или даже
def f(a, b,
c):
pass
и в случае длинного (зачастую из-за названий параметров, указания дефолтных значений, типов и т.п.) списка параметров приходится прибегать ко второму или третьему варианту, но в случае короткого используют первый.
Не лучше ли было бы, если бы второй или что-то типа него было бы единственно разрешённым? Разнообразие в этом лично мне кажется «untidy», а третий вариант (который зачастую выбирают IDE при автоматическом форматировании) как по мне и вовсе исчадие «ада перфекциониста».
Ни в коем случае не настаиваю и сам не уверен, просто подумалось, решил вынести на суд коллективного разума.
А как же минификация?
def f(a, b, c):
pass
— хороший вариант, если нет комментариев
def f(a,
b,
c):
pass
— плохой вариант, если нет комментариев, но, который легко превращается в очень хороший, если добавить комментарии
def f(a, # комментарий a
b, # комментарий b
c): # комментарий c
pass # итоговый комментарий
PS с Питоном не знаком, просто нагуглил аналог // из C++
Тогда уж хранить код в виде AST, а в редакторе разворачивать с применением персонального файла стилей.
Минус данного подхода: как хранить AST в системе контроля версий?
Так и хранить, отформатированным в виде текста.
1. Размер деревьев. Число токенов на порядок-два (зависит от ЯП) больше числа строк.
2. Деревья — двумерные структуры. СКВ работают преимущественно с классическими операциями Левенштейна (добавить, удалить, заменить строку). Много ли Вы знаете СКВ, которые бы отличали <удалить строку A №5 + вставить строку A перед строкой B №4> и <поменять местами строки B №4 и A №5> и корректно сливали эти патчи с другими? Для AST необходимо же исходно поддержить как горизонтальные операции (добавление/удаление дочернего поддерева), так и вертикальные (замена поддерева его дочерним поддеревом/замена поддерева T на C[T] для некоторого контекста C[] с одним подстановочным местом). Вроде бы это обстоятельство меняет асимптотическую сложность.
И ещё обращаю внимание, что получение диффа — более простая задача, чем построение модели (в т.ч. с конфликтным/бесконфликтным слиянием патчей) СКВ.
P.S. Я полностью согласен с последним: если когда-то СКВ научатся работать с AST и будет унифицированный формат деревьев, инструменты программирования шагнут на принципиально другой уровень удобства.
Как-то решение сразу не пришло в голову.
Можно сформировать отдельный файл стилей для хранения.
При загрузке переформатировать в пользовательский формат, при сохранении — в машинный.
Я вот думаю, хорошо бы если бы IDE при сохранении форматировала стандартным образом, а при загрузке — по настройкам пользователя. Тогда бы и взаимодействие в команде не страдало бы, и редактировать код в своем стиле было бы удобнее.
так и стремится удалить лишние строки, пробелы, выстроить выражение по своему образцу.
лучше бы сделали подобную опцию опциональной. ломать через колено это неприятно, после других то языков.
PS Хотя и вручную я тоже стараюсь придерживаться какого-то (чаще всего наиболее читабельного) форматирования кода.
То есть важнее договориться одинаково, чем сделать как то особенно правильно.
В этом смысле имеет смысл смотреть на стандарты для языка — от мейнтейнера, популярной ide или стандартных модулей.
Перешел на prettier с standardJs — Это просто божественно — да, в нем мало настроек, по началу это бесило (например нельзя в реакте сделать ковычки на пропсах одинарными) — но сейчас я понимаю что вообще больше руками не форматирую код — все делается автоматически за меня.
Я не представляю себе ситуацию чтоб я вернулся к ручному форматированию.
Но у преттиера есть минус — он немного сырой и кое-где ведет себя странно, с теми же промисами
Дак нет, он реально плохо чайнит промисы.
Вроде в новых версиях это поправили каким-то костылем, что-то типа "если есть слово than значит чайним все на новую строку, если слова нет то чайним в одну если помещается и меньше двух точек, инача все на новую строку"
Собственно из-за этого он переносит в моем случае адрес запроса на новую строку
api
.get(`/ajax/report/${id}/info`)
.then(res => {
// Handle
Хотя я привык к чему-то типа
api.get(`/ajax/report/${id}/info`).then(res => {
// Handle
Скопировал ваш код, получил такой формат как вы и хотите: ссылка на онлайн-демо
if (food == 'pizza')
{
print('Pizza ;-)');
}
else
{
print('Not pizza ;-(');
}
Есть еще кое-что, что никто кроме меня не делает. Я всегда использую двойной пробел перед комментарием в конце строки.
Я думал, это улучшает читабельность кода. Но, на самом деле, это делает кодовую базу несогласованной, потому что остальные разработчики ставят только один пробел.
Например с точки зрения python pep8 рекомендуется как раз делать два (как минимум) пробела перед # в инлайн-комментариях.
В итоге, не стоит полагаться на какие-то абсолютные правила, а имеет смысл договориться в и приянть стиль оформления в своей команде. Не вижу проблем, разработчики не будут явно придумывать обфускаторы, а сделают так, как читабельнее для них, и пусть это будет отличаться он неких догматических «стандартов».
Намного лучше и удобнее
if (food == 'pizza'){//комментарий if
print('Pizza ;-)');}
else{//комментарий else
print('Not pizza ;-(');}
another.code();//следующий код с начала строки
— выделяется целиком весь блок if-else, и видно, где он кончается
— выделяется, где else
— компактно, и на экране можно одним взглядом охватить больше кода
Можно и так:
if (food == 'pizza'){//комментарий if
print('Pizza ;-)');}
}else{//комментарий else
print('Not pizza ;-(');
}
another.code();//следующий код с начала строки
PS судя по минусам в Карму, у Вас явно не хило бомбануло, от указания недостатков варианта:
if (food == 'pizza')
{
print('Pizza ;-)');
}
else
{
print('Not pizza ;-(');
}
Вариант
if (food == 'pizza')
{
print('Pizza ;-)');
}
else
{
print('Not pizza ;-(');
}
— это классика от Кэрригана и Риччи, созданная тогда, когда шли жаркие споры о том, что "форматирование и отступы — вообще не нужны", и потому ими был выбран именно такой компромиссный вариант, оказавшийся, как это выяснилось позже, "ни рыба, ни мясо".
Вот потому холивары и идут до сих пор, куда ее ткнуть, — за условие или в отдельную строку, или в блок, потому что она реально нигде не нужна.
Почему роботы должны форматировать код за нас