Pull to refresh

Comments 96

О, это уже очень хорошо. Спасибо большое!
У меня так.
Префикс n / суффикс Count, в зависимости от типа кода — только для счётчиков.
Префикс i / суффикс Index — только для порядкового номера.
Id — только для идентификатора, не изменяющегося с перенумерацией.
Quantity (Qty), Number (No) — только для вещей, которые так называются в реальной жизни (StartingNo — стартовый номер, ReynoldsNo — число Рейнольдса...)
Что-то как-то не вызывает доверия статья, содержащая грубые ошибки в переводе.
You can have a discount depending on the quantity of details you buy.
В зависимости от того, сколько запчастей вы купите, вы сможете получить скидку.
— эта фраза переводится как «вы можете получить скидку, размер которой зависит от количества купленных вами деталей».
С чего вы взяли, что размер скидки зависит от количества деталей?
Впрочем, да. Но смысл один и тот же, по большому счету.
там так и написано, английским по белому: «discount depending on the quantity».
Смысл всего предложения — как раз таки сообщить, что скидка зависит от объема. В русском переводе авторов статьи нет слов «размер скидки зависит», там просто упоминается скидка и количество. То есть при переводе утерян главный смысл. По большому счету или не по большому, но за такие ляпы, например, на бизнес-переговорах переводчиков увольняют за профнепригодность. И расстреливают.
А я понял, что такое пафос! (:
Он самый. Который сатирический. Я надеюсь, получилось :)
Я так смотрю, вы не одиноки %)
О боже, нельзя из-за такой мелочи ТАК нервничать! У вас аж мысли путаются

И да, таки третий топик был лишним. Всё уже устаканилось, успокоилось. И вы не поняли главной идеи второго поста. Его основная цель была не убедить, что табы лучше, а научить людей пользоваться (раз уж они ими пользуются)
Да я все идеи отлично понял. Но не мог же я упустить такой прекрасный случай побуйствовать :)

А заодно рассказать про perltidy и про то, как хорошо пользоваться хуками.
Буйствуйте так почаще. Те 5 минут что я потратил на прочтение, были пока лучшими на этой неделе. И не то чтоб я был со всем согласен (хотя почти) просто очень хорошо написано, «живо» что ли, но при этом без соплей…
UFO just landed and posted this here
По такой логике лишним как раз был первый топик, а второй нужен был для баланса. Тем более, основная идея у него как раз «как правильно использовать табы», а не «табы вс пробелы». Ну и да, куча народа с вами не согласны.
Э-э-э, где путаются? Я поправлю.
я правильно понял что основная проблема, раскрываемая в топике, что vim can't into double \n? =)
Нет, это просто иллюстрация. Стрипанье пробелов тоже имеет сторонников и противников.
Может и не путаются, но выражаетесь вы сумбурно. Вон inikulin тоже ничего не понял.
Когда я писал в vim, это было моей проблемой. Кажется, она даже как-то решалась.

Теперь в vim пишешь ты (а я в Komodo Edit), но почему-то это осталось моей проблемой. Почему? Потому что vim православнее? Вот не надо. В конце концов, я старше и у меня ноги грязнее. У нас субординация и выслуга лет.

О какой проблеме вы говорите? У вас проблемы с редактором? Я могу вам посоветовать хорошую IDE. Вы с другим программистом постоянно ссоритесь из-за стиля? Так определите style guide для проекта и не ссорьтесь.
И да, я (как читатель) не пишу в Вим. Если вы не про меня, то про кого?

Давай не будем друг друга в чем-то убеждать. У тебя свои табуляции, у меня свои. Не станем их навязывать. Каждый остается при своем, а чтобы оставаться было удобней, умные люди придумали обрабатывающие скрипты (hooks) на события в системах контроля версий.

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

* код в репозитории хранится с отступами, кратными 4 пробелам
* каждые 8 пробелов обязательно заменяются символом табуляции ASCII 0x09

И где-нибудь код от такого ужаса обязательно поедет

3. В первой версии поста количество матюков достигало трех штук на предложение. Скрепя сердце, матюки повыбрасывал. А то программист нынче пошел нежный, от табуляций и пробелов бледнеет и чахнет, куда ему крепкую лексику. Тут смайл.

Все весело похоливарили, и только Вы восприняли всё это так близко к сердцу, что написали топик, с трудом удержались от матов, пообещали позвать маму и т.д.)

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

Смысл, цель и идея топика, на мой взгляд, заключается в том, что проблема «табы или пробелы» является слишком раздутой и по большей части надуманной. О чём, собственно, и попытался поведать нам автор.

И пора завязывать решать несуществующие проблемы вместо того, чтобы наконец-то решать РЕАЛЬНЫЕ задачи.

Лично я всё понял именно так.
А какие реальные проблемы и как их решать? Поехать на Фукусиму с лопатой и убирать последствия катастрофы? Или по трупам пробираться вверх, и, в игоге, стать президентом мира, убив всех плохих человеков?

То, что происходит обсуждение табуляций и пробелов не означает, что паралельно не делается дело.
И да, вы сейчас опять же решаете «несуществующие проблемы вместо того, чтобы наконец-то решать РЕАЛЬНЫЕ задачи».

И да, кричать «не занимайтесь фигней» — прикольно. А чем заниматься? Поведете людей на праведное дело?
А какие реальные проблемы и как их решать?
Под «реальными проблемами» я подразумевал, собственно, решение конкретных рабочих задач вместо того, чтобы заниматься нытьём и рассказывать руководству что-то типа «я не перевариваю табы\пробелы и мне нужна неделя времени на то, чтобы перекроить существующие исходники так, как МНЕ будет понятно»

И да, вы сейчас опять же решаете «несуществующие проблемы...»
Я сейчас в своё удовольствие дискутирую на данную тему, которая мне не безразлична. И я целиком и полностью согласен с автором. Если внезапно ко мне придёт работать кто-то, для кого будет проблемой чужие табы или пробелы — то он у меня работать не будет, пускай он будет трижды мега-гуру. Вот и всё.
мне нужна неделя времени на то, чтобы перекроить существующие исходники так, как МНЕ будет понятно»

В любой ИДЕ табы меняются на пробелы и обратно за 5 минут ;)
Да и руководство тут ни при чём. Вопрос «табы или пробелы» стоит только перед тем, кто начинает новый проект или рефакторит проект, в котором не было стиля (при условии, что такой вопрос уже не решен на уровне языка).
Более того, я предлагаю решение этого вопроса. Железобетонное.
Читайте «Ответ на главный вопрос»:
1. Придумайте уже какое-нибудь решение по поводу пробелов и табов в файле.
2. Обеспечьте его commit-hook'ом в репозитории.
3. Если кто-то предпочитает другое решение, пусть обеспечивает его сам при выгрузке кода.
Вот, так то намного лучше! Это штуку надо было сделать вступлением в топик (до хабраката), а в теле написать, например, о том, как сделать легко commit-hook в разных CVS. И тогда топик был бы интересным и полезным, а не таким как сейчас)
Могу посоветовать еще один обрабатывающий скрипт. Он переставляет строки файла в обратном порядке, снизу вверх %)
О какой проблеме вы говорите? У вас проблемы с редактором? Я могу вам посоветовать хорошую IDE.

Даже в цитате указано, какой IDE я пользуюсь :)

А проблема в том, что программисты жалуются друг другу и друг на друга — на предмет того, кто какие пробельные символы коммитит.

Я рад, что у вас свои табуляции, но в нашем проекте есть стандарты кодирования и вы должны их соблюдать … все коммиты в проект должны идти в одном стиле.

Хм. А я про что?

И где-нибудь код от такого ужаса обязательно поедет

Где поедет? В чьем-то редакторе? Опять же, а я про что пишу?

Не понятен ни смысл, ни цель, ни идея.

Ну извините :)
Даже в цитате указано, какой IDE я пользуюсь :)

Я заметил и, простите, ею не пользовался. Могу посоветовать IDE без проблем

Хм. А я про что?

Не знаю. Мне показалось, что о том, что «У тебя свои табуляции, у меня свои».

Где поедет? В чьем-то редакторе? Опять же, а я про что пишу?

Где-то. Вы предлагаете в одном месте использовать паралельно табы и пробелы. Оно будет ехать при неправильном размере табов, при вставке кода на форуме и т.д.

Опять же, а я про что пишу?

Опять же, я так и не понял, о чём вы пишете.

Ну извините :)

Та без проблем, не нервничайте из-за этого, когда-то извиню))
Я заметил и, простите, ею не пользовался. Могу посоветовать IDE без проблем

Разве я сказал, что у меня проблемы с Komodo Edit?

все коммиты в проект должны идти в одном стиле.
Хм. А я про что?

Стоп. Вы не топик дочитали до конца?
Ну вы в топике написали, что в работаете в Komodo Edit и из-за этого у вас проблемы:
Теперь в vim пишешь ты (а я в Komodo Edit), но почему-то это осталось моей проблемой.


Стоп. Вы не топик дочитали до конца?

Читал два раза, но часть мыслей так и не понял)
Друг (кстати, почти земляк), уже глубокая ночь, давай друг друга понимать утром будем. На свежую голову.
Ладно, кому-то оно действительно придётся по душе ;)
Да ну, прямо-таки путаются. Лично я всё чётко понял и солидарен с автором, так что…
Это просто великолепнейший стиль написания статьи. Огромное вам спасибо за отличное настроение на весь день.
Кстати, полностью с вами согласен, пожалуй, лучший способ решить проблему стиля написания кода: там где можешь — используй то, что тебе удобно, там где нужно — используй то, что сказано, и когда нужно — превращай одно в другое.
Спасибо! Но матюгов жалко, честное слово.
Ух ты, наконец-то я узнал еще одного человека, кто тоже пишет в Komodo!
А чем лишний LF в конце файла не угодил?
Просто пример, не более.
Например, шаблонизатор в php на основе eval или подобный.
В PHP файлах в таких случаях обязательно надо ставить в конце "?>" (тоесть открытый <?php без закрывающего выдаёт ошибку).
Да, я понимаю что все советуют не писать "?>" в конце, а прямо сейчас взять и переделелать чьё-то где-то ядро, чтобы не было eval, чтобы include был и так далее. Вопрос далеко не в этом. А в том, что лишний \n в конце файла вернёт лишний символ в выдачу, а это уже гораздо страшнее.

В таких случаях тупо невозможно создать файл, который открывается на <?php и закрывается на ?>. Чем не пример? Многие редакторы не вставляют то, чего не просят. Некоторые редакторы считают себя умнее.

Простейший пример — берём древний сайт, созданный давным давно, и перносим его на другой хостинг. Делали не мы, исправлять не нам. Открываем config.php, меняем пароль от БД, сохраняем, сайт начинает сыпать ошибками заголовков (Headers already send).
Материмся и ищем, кто виноват (IDE святой, его руками не трогать, ведь у нас есть универсальный аргумент у меня всё работает, я уже три года на нём пишу!).
Один \n после закрывающего тега игнорируется, так что в выдачу он ничего не вернёт.
Ох, и правда, перепроверил, век живи-век учись.
Слёзно прошу прощения, но случай с закрывающим переносом когда то действительно имел место. Видимо, их (переносов) было два.
Перехожу на другую сторону баррикад.
Да ничем. Есть не просит, может жить. Но если уж чистить всё, так зачем их оставлять?
Еесть подозрения, что писал я почти о том же самом (тыц) вот только уложился в пяток приложений, да и яснее как-то излагал, правда без пафосу =)

PS: есть одно большое но! Действительно правильный хороший форматёр-преобразователь из одного стиля написания в другой — это очень сложно. И без полноценного анализатора ЯП тут не обойтись. А ведь «холивар» о пробелах и табуляции — это лишь малая часть проблем со стилем при коллективной разработки. Это хорошо, когда в сообществе/команде есть принятые нормы написания кода (как в Rails, например. А вот в Node.JS — ещё нет — надо разрабатывать =) ). Но, увы, иногда обнаруживаются исключения, благо их всё меньше — и это радует.
Вы именно об этом и писали. И я с вами обоими согласен на все 100%.
Ага. Все так и есть. Хорошо у вас в конторе :)

И да, переформатирование стиля — задача о-о-очень непростая. Полноценный парсер — это обязательно, и это меньшая часть задачи (парсер готовый от компилятора можно взять). А дальше еще миллион дел с теми же самыми выравниваниями, будь они не ладны. Потому и хороших форматтеров мало.
Чувствуется наболело. Сложно сказать какой язык использует автор, к счастью современные Ява IDE уже настолько умные что давно захватили человечество и я не слышал про проблемы с пробелами/табами уже лет так десять. Зато всех девелоперов которые запускают авто формат кода перед комитом, мы позорим и критикуем.

В общем действительно автор прав — пробелема есть у кого-то и есть, то это его проблема.
Автоформат усложняет сравнение версий (особенно для больших файлов), но однозначно упрощает чтение. Так что… не совсем понятно за что позорить, особенно если автоформат использовали и перед прошлым выкладыванием.
не фишка в том, что если все насильно автоформатируют, то не усложняет. А позорим как раз чтобы все автоформатировали это форсит использование определенного стиля и существенно упрощает возможные мерджи.
Ну это логично. Просто Вы писали:
> Зато всех девелоперов которые запускают авто формат кода перед комитом, мы позорим и критикуем.
Я это понял так, что вы позорите за автоформатирование, вот и удивился — почему так. Если все в точности наоборот, то да, я полностью согласен.
Язык здесь не важен.

А за что позорите-то? Просто потому, что сам изначально не пишет аккуратно? Ну так если неаккуратности свои не коммитит, то вроде грех небольшой.
язык важен в том плане, что IDE для разных языков существенно по разному развиты. Я всегда говорю — используя для разработки IDE отличную от IDEA или Eclipse вы воруете деньги фирмы (если вы не мега крутой чел который может делать все поперек и все равно будет получаться ОК).

позорим как раз за то, что если чел комитит не авто форматированный код, то потом человек который комити за ним и применяет стандартный стиль автоформатированием — получает кучу якобы изменений которые он не делал.
— для разработки на Яве. (выпало из контекста)
Есть же множество прекрасных тем для холиваров:… IE или FF ...

Какая толстая у Вас ирония
Я что-то тоже запнулся на этом сравнении)
Смачно написано. Спасибо. Автор, пиши ещё :)
  • код в репозитории хранится с отступами, кратными 4 пробелам
  • каждые 8 пробелов обязательно заменяются символом табуляции ASCII 0x09

Лицоруканога.гиф
Я стесняюсь спросить, нога здесь откуда? %)
Это комбо такое, суперфейспалм.
вся проблема тут в нетерпимости к чужому коду. каждый хочет, чтобы остальные писали код также как он сам. а необходимость читать в чужом стиле вызывает жуткий баттхёрт, куда уж там писать. и пресловутые стайлгайды — не решение. это лишь формализованное «старший разработчик привык так кодить, поэтому все ОБЯЗАНЫ соблюдать этот стиль». а при использовании хуков как сказано в статье — тому разработчику, который протолкнул свой стиль кодирования, никакие хуки настраивать не нужно будет, а вот всем остальным — извольте повозиться. самое страшное — когда в угоду стайл-гайдам жертвуется читабельность и слабосвязность строк кода (когда можно добавить/удалить строчку кода, не изменяя соседние — крайне полезно при слиянии).

да, и диффы без учёта пробелов — опасная вещь, особенно в языках с лесенкой }},},}}
А нетерпимость следствие наличия оформления в том, что должно описывать только логику. Я вот наконец оформил свою мысль
Какой-то бессмысленный пост, вы уж извините. Проблема между TAB и SPACE существует, а вы тут пишете про какую-то сложную специфику VIMа или чего там еще.
UFO just landed and posted this here
Ну нет, так резко я не собирался говорить :)
Угу, у нас в конторе тоже пытаются прикопаться к пробелам, причем очень не системно (где-то они хорошо, где-то плохо, где-то это якобы не пробел)
самый приятный и разумный пост за последнее время на Хабре. радует грамотность автора, потому что многие думают, что «скрепя сердце» пишется через «и». Чёрт, приятно, что в Киеве так хорошо знают русский.
хоть из поста ничего не понял, скажу просто Спасибо большое за него.
Более того, некоторые пишут «скрипя сердцем», новая идиома, ептыть.
Дык — так и есть: «укрепив сердце, ...»
proof
> Есть, скажем, такой спецэффект в vim'е: если между двумя строками с отступом затесалась одна совсем пустая строка (то есть в файле на ее месте два \n подряд), то vim не сохранял позицию курсора при перемещении вниз-вверх.

Ни разу не замечал. Сейчас проверил — спецэффекта нет. Наверно это было очень давно.

> Теперь в vim пишешь ты (а я в Komodo Edit), но почему-то это осталось моей проблемой. Почему? Потому что vim православнее? Вот не надо. В конце концов, я старше и у меня ноги грязнее. У нас субординация и выслуга лет.

Есть одна (международная) фирмочка в которой есть один сотрудничек с общим числом (не только непосредственных) подчинённых около пятидесяти. Пишет в vim. :P
UFO just landed and posted this here
написать фильтр, превращающий любой текстовый файл в излюбленную кандидатом комбинацию пробельных символов для отступов. Не справился за 20 минут?

Синтаксический анализатор за 20 минут? :)
Ну шо вы такое говорите, зачем парсер для того, чтобы причесать пробелы и табы в каждой строчке? Исключительно регулярками можно.

И даже программировать не обязательно. В консоли expand / unexpand.
Регулярки корректно обрабатывающие все возможные сочетания кода, комментариев, строк, случаи встраивания кода (как PHP) и т. п.? Возможно, конечно, но за 20 минут не факт, что успеет каждый бы, кто устроил по другим критериям. Про
if (...) {
    ...
}

if (...)
{
    ...
}


if (...)
    {
        ...
    }


и т. п. вообще молчу :)
Шарп, например, имеет контекстно-свободную лексическую грамматику. Это более широкий класс нежели регулярные грамматики. На регулярках там даже токенизацию нормально выполнить нельзя, какой уж там анализатор отступов и пробелов.
man expand

Какая к чертям токенизация? Того, что я хочу, не сделать за 20 минут?
Этот вариант работает лишь для текстовых файлов, которые правильно (согласно «вашей религии и предпочтениям») разбиты по крайней мере на строки. А это уже не «любой текстовый файл» — вспомните хотя бы холивары с "{".
Приходите на собеседование — я подробно опишу задачу.
Полноценное форматирование — не сделать. Либо я неправильно понял вашу задачу, что вполне вероятно и о чем я написал выше.
Согласен, то же самое для Java/C++ — да поможет Бог тому кто твердо решит описать регулярками всевозможные больные сочетания строковых литералов и комментариев, которые могут присутствовать в коде.
Эта проблема решается очень просто. Всем программистам при приёме в команду отдаётся документ на изучение с описанием стиля кодирования, принятого в команде. Членам команды намного легче примирится с любым стилем кодирования, если этот стиль был представлен им заранее, а не после пары чекинов написанного ими кода через замечания от тим-лида.

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

В «Совершенном коде» Макконнелла обсуждается этот вопрос. Глава 11.1.
Точно, там тоже, спасибо. Но я вот видел что-то близкое к тексту из первого комментария — то есть о том, что когда употребляется в английском.
Решается оч просто:

1) Билд менеджер или автомат перед коммитом запускает любой code beautifier, настроенный на style guide проекта.

2) Программер, который не согласен со styleguide после обновления запускает свой.
Все проще — давно пора уже делать такое IDE, которое хранит код не в виде текста, а сразу в виде синтаксического дерева. Все проблемы whitespace'ов исчезают автоматически :-)
Кстати, IntelliJ уже занялись подобным, сделав MPS.
Вообще-то, такие «IDE» уже давно применяют. Называются компиляторы в объектный код :) ну или в байт-код, или как хотите :)

А по существу — это все классно, но широкого распространения не скоро получит. Раз без IDE отредактировать исходник невозможно, то, скажем, быстренько достучаться к серверу по ssh и поправить ошибку в консоли уже не получится. Уже неудобство.
То, что я предлагаю, находится где-то между байт-кодом и текущим состоянием дел, когда код = текст. Существующие варианты байт-кодов не поддерживают взаимно-однозначное соответствие между синтаксисом и байт-кодом. Я же предлагаю взаимную однозначность для целей разработки. И стандартизацию подобного решения. А тогда уже любая IDE может это реализовать, стандарт-то будет открыт.
Может хватит статей про пробелы и табуляцию… Ладно была 1, потом 2-ая, так сейчас 3-ья, мрачная картина складывается. Личное мнение…
> чтобы оставаться было удобней, умные люди придумали обрабатывающие скрипты (hooks) на события в системах контроля версий.

> обязательное задание — написать фильтр, превращающий любой текстовый файл в излюбленную кандидатом комбинацию пробельных символов

> Быстренько гуглим: %твой_любимый язык% tidy. Скачиваем, ставим, прогоняем код через него

> Для %твой_любимый язык% ничего нет? Бери и пиши.

> Пусть Пупкин сегодня же настроит обрабатывающие хуки.

Боже, сколько действий нужно сделать и сколько человек надо анально покарать, чтобы решить «несуществующую» проблему…

А в это время вменяемые люди (тот же Гугол) просто пользуются пробелами.
предлагаю раскрыть следующие холиварные темы:
— какой отступ должен быть у скобок блока после if/for/while/…
— где должны находиться открывающая скобка?
— отступ return
:-D
появляются развесистые глупые диффы
Btw, нормальные дифферы умеют делать дифф с опциями вида:

— Ignore line ending differences
— Ignore white space length differences
— Ignore all white space differences.
Only those users with full accounts are able to leave comments. Log in, please.

Articles