Комментарии 108
Я думаю, что все общепризнанные стандарты имеют право на существование. А вот что не надо делать — так это изобретать свои стандарты, например, один мой коллега закрывающие фигурные скобки пишет в одной строке. Читается это противно. А другой коллега напротив КАЖДОЙ строки пишет комментарий, что она делает — по сути дублирование кода на русском языке. Читается еще противнее.
Вы просто привязались к своему стандарту. Автор хорошо сказал: «сильнее всего на отношение к стандарту влияет знакомство с этим самым стандартом». То, что вы считаете свое мнение константой — в корне неверно.
К примеру мне нравится, когда комментарии есть напротив каждой строки также, как и краткое описание класса до его начала.
К примеру мне нравится, когда комментарии есть напротив каждой строки также, как и краткое описание класса до его начала.
Я привязался не к своему стандарту, а общепризнанным. Даже венгерскую нотацию и то признаю. А теперь представьте реальный проект, в котором напротив каждой строки идет комментарий. Как минимум, это усложняет внесение правок: помимо правки кода, я должен изменить комментарий, а также выровнять их по горизонтали. Комментарий должен пояснять код и разъяснять неочевидные места, а не дублировать весь код:
int calcSum(int[] elements) // Метода для подсчета суммы элементов в массиве
{
int result = 0; // Объявим результирующую переменную result
for (int i = 0; i < elements.Length; i++) // Для каждого i от 0 до длины массива elements
{
result += elements[i]; // Прибавим к result i-тое значение массива elements
}
return result; // Возвратим значение result
}
Могу сказать только о том, что каждый раз, когда я делаю ревью древнего legacy-класса, в котором какой-то добрый человек автоформаттером IDE подогнал всё под текущие стандарты, у меня неистово бомбит.
Хотя бы потому, что конкретные изменения по таску найти сложновато.
Хотя бы потому, что конкретные изменения по таску найти сложновато.
Для этого для автоформата legacy обычно делают отдельный коммит.
НЛО прилетело и опубликовало эту надпись здесь
Это полбеды. Когда еще заботливый форматтер переставляет декларации в файле в "правильном" порядке, какие-либо изменения вообще отследить невозможно, ломается даже "Show Git history for method"
НЛО прилетело и опубликовало эту надпись здесь
А можно конкретнее чем json непригоден?
Отсутствие комментов, один вид кавычек, необходимость эти кавычки ставить в ключе, отсутствие trailing comma (это когда нельзя делать так: [1, 2, 3,]), скудность типов. Это из того, что сразу вспомнилось.
Вы перечислили несколько важных преимуществ JSON'а, которые, собственно, людей к нему и привлекают и облегчают его использование — в чём проблема-то?
P.S. Вы, возможно, хотели сказать, что JSON не слишком удобен для написания его человеком — что, отчасти, правда, но… наши недостатки — продолжение наших достоинств. Там где удобство чтения/разбора важнее удобства напиcания (то есть почти везде) всё, что вы перечислили — достоинства.
P.S. Вы, возможно, хотели сказать, что JSON не слишком удобен для написания его человеком — что, отчасти, правда, но… наши недостатки — продолжение наших достоинств. Там где удобство чтения/разбора важнее удобства напиcания (то есть почти везде) всё, что вы перечислили — достоинства.
Отсутствие комментов
1. Комментарии свели бы всю красоту лаконичности формата к нулю.
2. Формат является «обрезанным» способом записи объектов в JS и предназначается скорее для общения техники, нежели людей.
3. В JS комментарии были.
4. Пришлось бы изобретать еще одну форму записи.
5. Привело бы к усложнению (и замедлению) парсеров.
6. Поскольку формат свободный (в том смысле, что нет аналога схем xsd и dtd), то ничто не мешает добавить «лишние» данные в качестве комментариев.
один вид кавычек
Единообразие — прекрасно! Кстати, в статье обсуждался этот вопрос, в абзаце про legacy.
необходимость эти кавычки ставить в ключе
Скорее, для совместимости с JS, чтобы не ломать голову ни человеку, ни машине, как интерпретировать ключ.
отсутствие trailing comma
Опять же, для упрощения интерпретации, обход возможных неоднозначностей (не понимать ли запись ",]" как еще один пустой элемент?)
скудность типов
А зачем в данных разнообразие типов? Не думаю, что в JSON очень уж нужно различать знаковые и беззнаковые целые, например.
Т.е. JSON как формат, не слишком нуждающийся в упаковке (скажем, сравните с избыточностью XML) прекрасно справляется со своей функцией краткой записи данных и простоты разбора\генерации, не потеряв при этом в читабельности. Это как раз то, почему он так популярен, вовсе не «Совершенно непригодный для промышленной разработки академический стандарт».
Кроме того, он совсем не мешает жить другим не менее популярным форматам, таким, как HAML\YAML, например. Тем не менее, и они имеют свои преимущества и свои недостатки, а потому и используются совсем не там, где JSON, там бы они не подошли.
Ну и наконец, популярность != засилие, не надо, пожалуйста, вот этого " И как будто так и надо. Пофигизм и безволие."
НЛО прилетело и опубликовало эту надпись здесь
Соглашусь, что так было бы удобнее… Если бы было… Ну а на «нет» и суда нет, как уж получилось.
Не было бы так «удобнее». Вот как раз все рассуждения выше выдают их академичность. «В траффик» он их пускать не будет, ага. Свободы и стандарта он хочет. Какого стандарта? Такого?
А ведь недавно куча сайтов так выглядели — и в книжках именно так рекомендовали писать.
Ещё раз: либо комментариев у вас в стандарте и в соответствующих документах нет (а тогда и вырезать нечего), либо они есть — а тогда их под что-нибудь важное приспособят (и тогда они, по большому счёту, перестанут быть комментариями — но мы вроде о практике тут говорим, а не об академических изысках).
Отсутствие комментариев в JSON — это очень важное практичнеское преимущество этого стандарта. Если конкретно в вашей программе вы хотите-таки иметь комментарии — ну так разрешите их, это-то как раз несложно.
Но таки именно то, что куча парсеров не признают комментариев и гарантирует, что всевозможные шаблонизаторы (где комментарии могут быть как раз вполне уместны) вырежут комментарии до того, как файл превратится в конечный JSON, который вы будете отдавать кому-то ещё и «в траффик» они не пойдут — что может быть практичнее?
Кстати о практичеости. Заметьте, что JSON пришёл в мир, где всё уже было «предрешено»: «все идут в XML, всё идёт в XML, везде будет XML». В 2001м, когда JSON появился, уже были и XML-RPC/SOAP и XHTML и куча других вещей. И там было и «разнообразие» и «валидация» и много всего другого. И даже комментарии, кстати.
А потом появился JSON — и прочие языки обмена данными стали почему-то менее популярны. Можно долго спорить — почему это произошло, но говорить о том, что это «академический стандарт» — это уже Оруэлл: JSON был «слеплен из того, что было» и решал практические задачи — какая ж тут академичность?
Вот «хотелки» не решающие ровным счётом ни одной задачи и исходящие из того, что люди будут обладать свободой и при этом будут соблюдать стандарты (ага, щаз: это же люди, а не ангелы) — вот это как раз «академичный подход», не имеющий к практике никакого отношения.
Потому что у вас получается, что если Google переводит GData в 2005м с XML на JSON, то это происходит потому, что JSON в 2016м используются «буквально везде». У нас тут не Океания пока и логика «Океания всегда воевала с Остазией» не работает: всё-таки причина появляется перед следствием. Если в 2005м GData начинает поддерживать JSON — то это происходит потому, что он был удобнее, чем альтернатива, а не потому, что в 2016 JSON используется «буквально везде».
P.S. Используется «буквально везде» — кстати отличный пример практического довода. И хотя он не перешибает всех других доводов (иначе бы и на JSON никто переходить не стал и переход на IPv6 не происходил бы), но он — действительно весьма весом. Когда вы приходите со своими идеями «а давайте миллионы компаний потратят миллиарды долларов, чтобы я смог получить экономию в три секунды и десять центов», то ваши предложения отвергаются не из-за того, что кругом «пофигизм и безволие», а просто потому что людим кругом умеют считать деньги и время. Чего вы, похоже, babylon делать не научился пока.
P.P.S. Кстати форматы далеко не все остаются в неизменном состоянии. В качестве примера — посмотрите на Markdown и его превращение в CommonMark. Вот там совместимость — не была основным достоинством формата и потому расширения было делать проще. Однако в конце-концов это изрядно всех «достало» и стандарт всё же появился. Посмотрим — приживётся ли. А у JSON'а — его простота, лаконичность, неизменность и совместимость (сначала с JavaScript/ActionScript, сейчас — с сотнями, если не тысячами, парсеров) — это основное достоинство. Неудивительно, что идеи отказаться от него в угоду секундной экономии отвергаются! Где вы тут видите «академичность»?
<html>
<body>
<script type="text/javascript">
//<!--
document.write("Hello World!");
//-->
</script>
</body>
</html>
А ведь недавно куча сайтов так выглядели — и в книжках именно так рекомендовали писать.
Ещё раз: либо комментариев у вас в стандарте и в соответствующих документах нет (а тогда и вырезать нечего), либо они есть — а тогда их под что-нибудь важное приспособят (и тогда они, по большому счёту, перестанут быть комментариями — но мы вроде о практике тут говорим, а не об академических изысках).
Отсутствие комментариев в JSON — это очень важное практичнеское преимущество этого стандарта. Если конкретно в вашей программе вы хотите-таки иметь комментарии — ну так разрешите их, это-то как раз несложно.
Но таки именно то, что куча парсеров не признают комментариев и гарантирует, что всевозможные шаблонизаторы (где комментарии могут быть как раз вполне уместны) вырежут комментарии до того, как файл превратится в конечный JSON, который вы будете отдавать кому-то ещё и «в траффик» они не пойдут — что может быть практичнее?
Кстати о практичеости. Заметьте, что JSON пришёл в мир, где всё уже было «предрешено»: «все идут в XML, всё идёт в XML, везде будет XML». В 2001м, когда JSON появился, уже были и XML-RPC/SOAP и XHTML и куча других вещей. И там было и «разнообразие» и «валидация» и много всего другого. И даже комментарии, кстати.
А потом появился JSON — и прочие языки обмена данными стали почему-то менее популярны. Можно долго спорить — почему это произошло, но говорить о том, что это «академический стандарт» — это уже Оруэлл: JSON был «слеплен из того, что было» и решал практические задачи — какая ж тут академичность?
Вот «хотелки» не решающие ровным счётом ни одной задачи и исходящие из того, что люди будут обладать свободой и при этом будут соблюдать стандарты (ага, щаз: это же люди, а не ангелы) — вот это как раз «академичный подход», не имеющий к практике никакого отношения.
Потому что у вас получается, что если Google переводит GData в 2005м с XML на JSON, то это происходит потому, что JSON в 2016м используются «буквально везде». У нас тут не Океания пока и логика «Океания всегда воевала с Остазией» не работает: всё-таки причина появляется перед следствием. Если в 2005м GData начинает поддерживать JSON — то это происходит потому, что он был удобнее, чем альтернатива, а не потому, что в 2016 JSON используется «буквально везде».
P.S. Используется «буквально везде» — кстати отличный пример практического довода. И хотя он не перешибает всех других доводов (иначе бы и на JSON никто переходить не стал и переход на IPv6 не происходил бы), но он — действительно весьма весом. Когда вы приходите со своими идеями «а давайте миллионы компаний потратят миллиарды долларов, чтобы я смог получить экономию в три секунды и десять центов», то ваши предложения отвергаются не из-за того, что кругом «пофигизм и безволие», а просто потому что людим кругом умеют считать деньги и время. Чего вы, похоже, babylon делать не научился пока.
P.P.S. Кстати форматы далеко не все остаются в неизменном состоянии. В качестве примера — посмотрите на Markdown и его превращение в CommonMark. Вот там совместимость — не была основным достоинством формата и потому расширения было делать проще. Однако в конце-концов это изрядно всех «достало» и стандарт всё же появился. Посмотрим — приживётся ли. А у JSON'а — его простота, лаконичность, неизменность и совместимость (сначала с JavaScript/ActionScript, сейчас — с сотнями, если не тысячами, парсеров) — это основное достоинство. Неудивительно, что идеи отказаться от него в угоду секундной экономии отвергаются! Где вы тут видите «академичность»?
>А зачем в данных разнообразие типов?
Попробуйте написать проект, где вам нужны даты/timestamp, которых в json нет. Скорее всего ваше мнение изменится довольно быстро.
Целые тут ни при чем совершенно — речь про то, что те типы, которых в языке нет, очень сложно однозначно восстановить при разборе, потому что я JSON нет и метаданных для типа, в том числе. Т.е. без схемы вы не можете понять, это вам пришло число, или дата в виде количества миллисекунд от начала эпохи, пришла строка или опять же дата в формате ISO 8601.
Попробуйте написать проект, где вам нужны даты/timestamp, которых в json нет. Скорее всего ваше мнение изменится довольно быстро.
Целые тут ни при чем совершенно — речь про то, что те типы, которых в языке нет, очень сложно однозначно восстановить при разборе, потому что я JSON нет и метаданных для типа, в том числе. Т.е. без схемы вы не можете понять, это вам пришло число, или дата в виде количества миллисекунд от начала эпохи, пришла строка или опять же дата в формате ISO 8601.
Нет ничего идеального. Но альтернатив с подобным соотношением простота/удобство/понятность/читаемость/однозначность как-то не видно. XML это ад в сравнении с JSON.
There are a two kind of peopleПростите, это на каком языке?
Очевидно, на английском. Возможно, на английском с ошибками. Вероятно, должно было быть ...kinds…
По идее, ещё артикль лишний. Мысль о том, что в статье, переведённой с английского, на видном месте большими буквами может красоваться надпись на том же английском сразу с двумя ошибками, показалось мне настолько невероятной, что я решил уточнить, правильно ли определил язык.
Возможно, у них программисты тоже имели не самую высокую оценку по английскому языку в школе)
Возможно, картинка была подготовлена рано утром или поздно вечером. Я тут в обед прочитал, что я написал рано утром на форуме — так у меня там тоже возникли вопросы к себе, насчет того, является ли русский язык мне родным или нет… Было стыдно.
Возможно, картинка была подготовлена рано утром или поздно вечером. Я тут в обед прочитал, что я написал рано утром на форуме — так у меня там тоже возникли вопросы к себе, насчет того, является ли русский язык мне родным или нет… Было стыдно.
three
if cond: return
а так же
и
if (cond) return;и
return if cond;Это вообще не то
Мой любимый пример из личной практики на тему фигурных скобок в однострочниках:
Собственно, когда система вышла в production и настройки логгинга были изменены, баг внезапно и вылез.
Что касается конкретно Вашего примера — тут в целом ок, т.к. условие и действие в одну строку.
if (logger.isLoggable(Level.DEBUG))
// level.debug("someDebugMsg");
doSomethingValuable();
Собственно, когда система вышла в production и настройки логгинга были изменены, баг внезапно и вылез.
Что касается конкретно Вашего примера — тут в целом ок, т.к. условие и действие в одну строку.
Такие вещи должны тестами ловиться.
каждую сточку тестами не покроешь.
Это как раз типичный пример того, когда простейшее стилистическое правило (всегда использовать фигурные скобки для блоков) позволяет избежать целого класса проблем.
Это как раз прекрасный пример где тест должен проверить что функция do_something_VALUABLE вызывается. Может вы еще правило йоды юзаете?
Вы реально пишете отдельный тест на каждый вызов в каждой функции? (Я подразумеваю, что типичные сценарии работы и так покрыты тестами).
И вы реально предпочитаете вместо чуть другого стиля кода писать дополнительные тесы дополнительными тесты?
И вы реально предпочитаете вместо чуть другого стиля кода писать дополнительные тесы дополнительными тесты?
подразумевается, что если это действительно valuable, то оно должно быть покрыто хоть каким-нибудь (unit/integration/acceptance) тестом
Хорошо, если там действительно существенная часть бизнес-логики, то да, она будет покрыта тестами и пролема отловится. Но что, если там что-то второстепенное? Например освобождение памяти или другого ресурса? Т.е. тоже valuable, но, возможно, не покрытое непосредственно тестом?
НЛО прилетело и опубликовало эту надпись здесь
Конкретно в этом куске кода тест скорее всего был бы успешен (в тестах обычно дебаг-логирование)
НЛО прилетело и опубликовало эту надпись здесь
У нас в фирме, например, очень строгое правило — закомментированного кода быть не должно. За 4 года было 2 исключения и каждое подробно описывалось рядом, почему и как.
Это на каком языке?
еще
if(cond)
{
return;
}
if(cond)
{
return;
}
Более того, в Питоне почти не бывает вопросов по поводу стилей кода, а всё потому, что фактически с самого начала есть подробный стандрарт: PEP8. Если подумать — это просто отличное решение. Сэкономило кучу времени куче людей.
Хорошо, когда можно сделать go fmt и никаких споров :)
И Ctrl + Alt + Shit + L в JetBrains IDE с попутным тыканьем новичков в доки по PSR (в стане PHP разработчиков), например.
Наверное go и php (современный) — это единственные языки, где никогда не возникает споров по поводу кодстайла.
У меня только один вопрос — зачем } else { на той же строке, что и закрывающая скобка?
Вопрос не верный, не "зачем", а "почему". Потому что PSR основан на самых популярных практиках самых популярных продуктов. Вот и весь ответ, никакого смыслового значения "зачем" в самом стандарте нет. Взяли и основали стандарт на том, что используют большинство.
Если искать смысл в самих корнях, то подобные практики пошли, я почти уверен, из миров java, haxe, c++ и прочих. Где подобное является стандартными вещами (ну в C\C++ несколько стандартов, так что моё утверждение на счёт подобной практики в этом языке лишь частично верное).
Размышления на тему: Положа руку на сердце, может это просто привычка использовать именно этот стандарт во всех языках, которые использовал (haxe, java, js\es, sass, less, php), но мне кажется что подобное лучше выглядит, нежели размазывание одного метода на 100500 строк. "Воздух" добавляется за счёт переносов строк, а законченное по смыслу логическое выражение, включающее этот самый "else" более компактно и лучше бросается в глаза, нежели если скобки переносить на новую строчку. Фиг знает, споры о кодстайле могут продолжаться вечность и "лучшего" всё равно не найти.
Я смотрел голосование по этой теме в PSR:
А) 10 голосов за
Б) 6 голосов за
Так что да, большинство, но очень не хватает их обоснований. По каким причинам этот голос. Потому что у меня есть несколько обоснований относительно варианта Б и слабые обоснования для А.
А) 10 голосов за
if () {
...
} else {
...
}
Б) 6 голосов за
if () {
...
}
else {
...
}
Так что да, большинство, но очень не хватает их обоснований. По каким причинам этот голос. Потому что у меня есть несколько обоснований относительно варианта Б и слабые обоснования для А.
Мне, например. вариант Б просто режет глаза. И я объясню почему: if..else это одна единая конструкция. Поэтому "} else {" выглядит как продолжение конструкции, а «else {» с новой строчки больше похоже на новую конструкцию, никак не относящуюся к предыдущему if-у. То же самое и с фигурной скобкой на той же строчке, что и сигнатура метода: код метода непосредственно относится к его сигнатуре.
Можно и в обратную сторону рассуждать: if..else — это единая конструкция, а }else{ — нет, потому что {}, т.н. блок — отдельная сущность.
Любая конструкция состоит из блоков, одного или несколько. Причем тут блоки? Я говорю именно про визуальное восприятие. Не пойму чем тогда по вашей логике отличается "}else{" от «else{»?
Конструкция так называется — «блок».
Есть условный оператор, есть операторы цикла, есть выбор по ключу, есть блок.
Вы же можете написать
for (...)
;
А можете в теле использовать не один оператор action, а блок.
Есть условный оператор, есть операторы цикла, есть выбор по ключу, есть блок.
Вы же можете написать
for (...)
;
А можете в теле использовать не один оператор action, а блок.
Если вы понимаете под блоком именно фигурные скобки, то согласен. Я понимаю под блоком кода, как ни странно, блок кода, ему не обязательно быть обрамленным в фигурные скобки и он может быть пустым, как в вашем примере с «for». Так что в действительности любая конструкция(будь то if, for или еще чего) не имеет смысла без блока кода.
Т.е. получается такая иерархия: лексемы -> выражения -> блоки -> конструкции.
Т.е. получается такая иерархия: лексемы -> выражения -> блоки -> конструкции.
Не я понимаю; так называется. Оно же — «составной оператор».
Например, КиР:
Например, КиР:
3.1 Statements and Blocks…
Braces { and } are used to group declarations and statements together into a compound statement, or block, so...There is no semicolon after the right brace that ends a block.
3.2 If-Else
The if-else statement is used to express decisions. Formally the syntax is
if (expression)
statement1
else
statement2
where the else part is optional.
Если у вас блок — отдельная сущность, вы придёте к GNU стандарту:
Мне лично не такой вариант не нравится (слишком много места пропадает зря из-за чего в GNU проектах любят не использовать фигурные скобки для однострочных выражений — и потом ясно, чем это кончается), но определённая логика тут есть.
Вариант же с «else {» — ужасен просто потому что у вас оказывается две отдельные, никак не связанные друг с другом конструкци: «if» и «else».
Вот «else { blah-blah-blah }» как прикажете понимать? Это вообще что такое? Это куда? Это зачем? Как так вообще можно писать???
if (...)
{
...
}
else
{
...
}
Мне лично не такой вариант не нравится (слишком много места пропадает зря из-за чего в GNU проектах любят не использовать фигурные скобки для однострочных выражений — и потом ясно, чем это кончается), но определённая логика тут есть.
Вариант же с «else {» — ужасен просто потому что у вас оказывается две отдельные, никак не связанные друг с другом конструкци: «if» и «else».
Вот «else { blah-blah-blah }» как прикажете понимать? Это вообще что такое? Это куда? Это зачем? Как так вообще можно писать???
Вас же не смущает конструкция «default: blah-blah-blah; break;». Ветки оператора switch пишутся отдельно друг от друга, и выглядят как отдельные не связанные конструкции. Почему бы и if так не писать?
весь switch — это одна конструкция, состоящая из нескольких case, которые, как вы правильно заметили, не связаны никак друг с другом. Поэтому так и пишутся :)
Я имею ввиду, что каждый следующий case не является продолжением другого, и один case может существовать без предыдущего. else в свою очередь не может существовать без предыдущего блока.
Я имею ввиду, что каждый следующий case не является продолжением другого, и один case может существовать без предыдущего. else в свою очередь не может существовать без предыдущего блока.
Тогда и try / catch надо отдельными блоками писать, потому что там catch не связаны между собой.
Цепочка if / elseif / elseif / else похожа на оператор switch, и elseif там тоже не связаны. case не может существовать без switch, catch не может существовать без try, else не может существовать без if.
PS: Писал так в одном проекте, когда ветки if идут отдельными блоками. Вполне нормально смотрится, код в блоках не сливается с предыдущими, особенно если условия длинные.
Цепочка if / elseif / elseif / else похожа на оператор switch, и elseif там тоже не связаны. case не может существовать без switch, catch не может существовать без try, else не может существовать без if.
PS: Писал так в одном проекте, когда ветки if идут отдельными блоками. Вполне нормально смотрится, код в блоках не сливается с предыдущими, особенно если условия длинные.
Тогда и try / catch надо отдельными блоками писать, потому что там catch не связаны между собой.Связаны. Если один оператор
catch сработал, то другой — уже ничего перехватить не может. Логически — это цепочка обработчиков (хотя внутри, конечно, компилятор может оптимизировать).Цепочка if / elseif / elseif / else похожа на оператор switch, и elseif там тоже не связаны.Связаны — тем же самым способом. Нельзя одну ветку рассматривать в отрыве от других.
case не может существовать без switch
Case и switch — это просто "goto под прикрытием". Он может скакать на любую глубину вложенности (правда не может мимо конструкторов и «наверх»), иерархии меток никакой нету. if/elseif/else и try/catch — устроены совсем не так.У оператора switch нет никаких «веток», извините. Когда вы используете низкоуровневую конструкцию с оператором goto, что часто у вас просто нет выбора.
Как вы предлагаете скобки в чём-то типа следующего расставлять:
В случае же с if'ом у вас есть две ветки, которые очевидным образом связаны между собой.
Как вы предлагаете скобки в чём-то типа следующего расставлять:
switch (i % 8) while (i > 0) {
case 0: x += a[ i-- ];
case 7: x += a[ i-- ];
case 5: x += a[ i-- ];
case 4: x += a[ i-- ];
case 3: x += a[ i-- ];
case 2: x += a[ i-- ];
case 1: x += a[ i-- ];
}В случае же с if'ом у вас есть две ветки, которые очевидным образом связаны между собой.
Если у вас блок — отдельная сущность
Так не у меня, так определяется стандартом, нет?
О, оказывается, самый логичный и верный на мой взгляд вариант имеет имя — GNU стандарт. Спасибо!
из-за чего в GNU проектах любят не использовать фигурные скобки для однострочных выражений
Ох, и тут совпадение.
Я бы сказал, что это очень старомодный стандарт, потому что легкочитаем без подсветки, в монохроме/на бумаге.
Так не у меня, так определяется стандартом, нет?Ну так стандарт и в выражении
a = b + c; несколько сущностей выделяет. Это не значит, что нужно в пять строк это писать.Я бы сказал, что это очень старомодный стандарт, потому что легкочитаем без подсветки, в монохроме/на бумаге.Угу — вот только часто получается, что читается и работает — программа по разному. Это — очень большая проблема.
P.S. Вообще, конечно, очень жаль что на проблему, которая, вообще-то, яйца выделенного не стоит, мы тратим столько времени. Причём забавно что в языках типа Make, которые, являются, в других отношениях, весьма убогими
этой проблемы нет. Естественная расстановка отступов в блоке ifeq/else ifeqelse/ — существует только одна, а споров о сущности «блоков» нету потому что никаких «блоков» нету. Это одна из вещей, которые в C/C++ сделаны отвратительно — но при этом, почему-то, это кривое и неудобное решение копируется везде и всюду…Ну так стандарт и в выражении a = b + c; несколько сущностей выделяет. Это не значит, что нужно в пять строк это писать.
Это натяжка, ну да ладно.
Угу — вот только часто получается, что читается и работает — программа по разному. Это — очень большая проблема.
В случае с
if <>
{
}
else
{
}
Исполняется так, как читается.
Вообще, конечно, очень жаль что на проблему, которая, вообще-то, яйца выделенного не стоит, мы тратим столько времени
Я просто порадовался, что такой стандарт есть, только и всего.
Это одна из вещей, которые в C/C++ сделаны отвратительно — но при этом, почему-то, это кривое и неудобное решение копируется везде и всюду…
В Паскале аналогично, только в силу обозначения составного оператора(блока) словами, споров вполовину меньше.
В случае сКак я уже сказал — этот стандарт мне не нравится, но я его понимаю. А вот
if <>
{
}
else
{
}
Исполняется так, как читается.
if <...> {
...
}
else {
...
}
if был отдельно и else — отдельно. И вот этого я не понимаю. «Отдельно живущий блок» — это ещё туда-сюда, но «отдельно живущий» else — это какая-то очень странная сущность.Угу. Для C/C++ есть clang-format, но у него есть большая беда: не все его используют.
Впрочем в проектах, его использующих, жить всё равно легче. Мне, в общем, всё равно как стоят пробелы (потому что почему-то тот вариант, который нравится мне редко нравится кому-либо ещё) и я ненавижу Style Guide'ы (по той же причине) — но спокойно отношусь к вещам подобным
Просто потому что когда мне дают
Впрочем в проектах, его использующих, жить всё равно легче. Мне, в общем, всё равно как стоят пробелы (потому что почему-то тот вариант, который нравится мне редко нравится кому-либо ещё) и я ненавижу Style Guide'ы (по той же причине) — но спокойно отношусь к вещам подобным
go fmt.Просто потому что когда мне дают
go fmt — то мой код делают хуже понимаемым лично мной, но взамен экономят немножко моё время. Это я ещё могу терпеть. Но когда мне навязывают какой-то Style Guide и не дают инструмента, то это значит, что меня заставляют тратить время и делать работу, которая мне же и сделает хуже! Это — уже перебор.Это абсолютно верная позиция, когда вы над кодом сидите один и никому не показываете. Но когда в команде больше 3х человек — не думаете ли, что подобные принципы немного эгоистичны? И что лучше использовать один стандарт, пнуть себя в мягкое место и переучиться (это тяжело, я прекрасно это понимаю, у каждого есть подобный опыт), который доступен и привычен большинству, нежели свой супер-удобный вариант, доступный только для таких, бесспорно замечательных разработчиков, как вы? =)
Нет, не проще. Заметьте: я не настаиваю на том, чтобы кодить игнорируя все и всяческие стандарты. Но. Стандарт либо содержит объективно-проверяемые вещи, либо нет.
Первое — автомат типа
Первое — автомат типа
go fmt способен проверить (а зачастую и исправить), второе — будет постоянным источником споров и разногласий независимо ни от чего.Ну меня просто смутила фраза "ненавижу всяческие стайлгайды", я рад что ошибся в вашей позиции. А стайлгайды, по-моему наоборот хорошо когда есть, главное чтобы он был один. Нравится ли он или нет — не важно, главное чтобы один, иначе холивары и всё такое. Короче, почти что как сейчас в комментах к посту.
Еще два типа:
return
return;
приведение к стандарту просто надо выполнять отдельным коммитом imho.
Но история всё равно портится.
Я обычно следую правилу, что если приходится править старый код, то форматирование меняю только на уровне отдельных методов, причем если в них изменилась довольно большая доля кода. Т.е. если поправили пару строчек в большом методе — оставляем стиль прежний. Если поправили треть метода или больше — тогда уже можно переформатировать весь метод.
Я обычно следую правилу, что если приходится править старый код, то форматирование меняю только на уровне отдельных методов, причем если в них изменилась довольно большая доля кода. Т.е. если поправили пару строчек в большом методе — оставляем стиль прежний. Если поправили треть метода или больше — тогда уже можно переформатировать весь метод.
Мы использовали
git filter-branch, чтобы привести всю историю к единому стандарту. Заодно избавились от части конфликтов при слиянии.А, т.е. ретроспективно исправили стиль во всём проекте как если бы он изначально писался с правильным стилем? Интересное решение.
Минус, конечно, что история меняется, но конкретно в плане исправления стиля — вроде и не страшно.
Минус, конечно, что история меняется, но конкретно в плане исправления стиля — вроде и не страшно.
Есть ещё такая точка зрения: если применять новые стандарты только к новому (изменённому) коду, то со временем будет повышаться читаемость часто модифицируемых кусков. Нетронутыми же останутся те, которые либо "просто работают", либо никому не нужны. Со всех сторон одни плюсы — и без лишних телодвижений и польза в нужном месте.
У нас есть стандарт. Он фиксирует спорные моменты по которым были разногласия, периодически дополняется. К проекту есть еще архитектурные заметки, из серии если вы в коде столкнулись с указанными областями, то с ними следует поступать вот так.
Описывать всё и вся не вижу смысла — всегда проще договориться и найти пример в существующем коде. Чем большее количество человек работают над одной базой кода, тем строже должен быть стандарт.
Описывать всё и вся не вижу смысла — всегда проще договориться и найти пример в существующем коде. Чем большее количество человек работают над одной базой кода, тем строже должен быть стандарт.
Отлично выразил, ЕМНП, Роберт Мартин:
PS: Как славно что в PHP есть PSR =) Сколько безсмыленных холиваров этим предотвращено!
не важно какое соглашение о стиле кодирования вы примите, важно чтобы вы его приняли!
PS: Как славно что в PHP есть PSR =) Сколько безсмыленных холиваров этим предотвращено!
Очевидно ли на первый взгляд, что оба блока делают одно и то же?
Не хочу показаться занудой, но shift же изменяет массив.
ИМХО Не так уж важно как пробелы и переводы строк расставлять. Не вижу даже ничего суперстрашного если разные файлы форматированы по разному — все равно все будет понятно. Лучше концентрироваться на сути, например для плюсов: заставлять использовать RAII, создавать новые типы исключений вместо использования системных, порядок инклюдов, запрет using namespace в хедерах, запрет блокирующих вызовов и т.д.
А можно подробнее про «порядок инклюдов»?
А потом вдруг надо чей-то файл подредактировать, а в нем разрброд и шатание. И вместо того, чтобы сконцентрироваться на коде, ты сидишь и думаешь, как бы так расставить скобочки, чтоб было консистентно с остальным проектом.
Кривой/неконсистентный стиль можно быстро и массово поправить каким-нибудь clang-format, а затем сделать проверку стиля в CI. Все. Проблема решена. Зачем ей посвящать столько времени и сил в холиварах?
Куда сложнее читать и фиксить спагетти код функции на 400 строк с однобуквенными переменными без комментариев и кучей хаков. Который еще и не работает если пойти чуть в сторону. Вот за что нужно убивать.
Хмм… стандарт разработки — не то же самое, что стандарт форматирования кода кмк.
Вечная тема. Если прокрутить Google страницы W3C валидатором, то покажет кучу ошибок… И это Google. Все очень индивидуально.
Важно наверное стандарты безопастности, а остальное уже на любителя.
Важно наверное стандарты безопастности, а остальное уже на любителя.
Если считать, что статья про стиль форматирования, а не про стандарты программирования, то у меня есть примерно такие раздумья:
1) утвердить какой-то любой стиль для коммитов.
2) наладить процесс так, чтобы участник после взятия мог запустить настроенный под себя beautifier.
3) а перед коммитом запустить beautifier обратно на утверждённый стиль (можно даже запретить коммит, если на сервере beautifier вернул код «ошибки»)
4) при этом опасные преобразования, типа уничтожения скобок, запретить по всей команде.
1) утвердить какой-то любой стиль для коммитов.
2) наладить процесс так, чтобы участник после взятия мог запустить настроенный под себя beautifier.
3) а перед коммитом запустить beautifier обратно на утверждённый стиль (можно даже запретить коммит, если на сервере beautifier вернул код «ошибки»)
4) при этом опасные преобразования, типа уничтожения скобок, запретить по всей команде.
НЛО прилетело и опубликовало эту надпись здесь
пытаться насаждать свой любимый стандарт стиля программирования — это лишь бесить всех, т.к. все точки зрения субъективны, а вот иметь стандарт структуры когда, куда как важнее
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нужен ли стандарт разработки?