Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 96
Что-то я никак не могу нагуглить инструкцию по применению num и count в идентификаторахНе совсем про программизм, но всё же в тему: Особенности употребления существительных quantity, number, amount, count.
О, это уже очень хорошо. Спасибо большое!
У меня так.
Префикс n / суффикс Count, в зависимости от типа кода — только для счётчиков.
Префикс i / суффикс Index — только для порядкового номера.
Id — только для идентификатора, не изменяющегося с перенумерацией.
Quantity (Qty), Number (No) — только для вещей, которые так называются в реальной жизни (StartingNo — стартовый номер, ReynoldsNo — число Рейнольдса...)
Префикс 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».
Смысл всего предложения — как раз таки сообщить, что скидка зависит от объема. В русском переводе авторов статьи нет слов «размер скидки зависит», там просто упоминается скидка и количество. То есть при переводе утерян главный смысл. По большому счету или не по большому, но за такие ляпы, например, на бизнес-переговорах переводчиков увольняют за профнепригодность.И расстреливают.
Смысл всего предложения — как раз таки сообщить, что скидка зависит от объема. В русском переводе авторов статьи нет слов «размер скидки зависит», там просто упоминается скидка и количество. То есть при переводе утерян главный смысл. По большому счету или не по большому, но за такие ляпы, например, на бизнес-переговорах переводчиков увольняют за профнепригодность.
я ничего не понял =(
О боже, нельзя из-за такой мелочи ТАК нервничать! У вас аж мысли путаются
И да, таки третий топик был лишним. Всё уже устаканилось, успокоилось. И вы не поняли главной идеи второго поста. Его основная цель была не убедить, что табы лучше, а научить людей пользоваться (раз уж они ими пользуются)
Э-э-э, где путаются? Я поправлю.
я правильно понял что основная проблема, раскрываемая в топике, что vim can't into double \n? =)
Может и не путаются, но выражаетесь вы сумбурно. Вон inikulin тоже ничего не понял.
О какой проблеме вы говорите? У вас проблемы с редактором? Я могу вам посоветовать хорошую IDE. Вы с другим программистом постоянно ссоритесь из-за стиля? Так определите style guide для проекта и не ссорьтесь.
И да, я (как читатель) не пишу в Вим. Если вы не про меня, то про кого?
Я рад, что у вас свои табуляции, но в нашем проекте есть стандарты кодирования и вы должны их соблюдать. Можете хоть хуки настроить, хоть индуса нанять, но все коммиты в проект должны идти в одном стиле.
И где-нибудь код от такого ужаса обязательно поедет
Все весело похоливарили, и только Вы восприняли всё это так близко к сердцу, что написали топик, с трудом удержались от матов, пообещали позвать маму и т.д.)
Ну и, кака я уже сказал, топик, в целом, сумбурен. Не понятен ни смысл, ни цель, ни идея.
Когда я писал в vim, это было моей проблемой. Кажется, она даже как-то решалась.
Теперь в vim пишешь ты (а я в Komodo Edit), но почему-то это осталось моей проблемой. Почему? Потому что vim православнее? Вот не надо. В конце концов, я старше и у меня ноги грязнее. У нас субординация и выслуга лет.
О какой проблеме вы говорите? У вас проблемы с редактором? Я могу вам посоветовать хорошую IDE. Вы с другим программистом постоянно ссоритесь из-за стиля? Так определите style guide для проекта и не ссорьтесь.
И да, я (как читатель) не пишу в Вим. Если вы не про меня, то про кого?
Давай не будем друг друга в чем-то убеждать. У тебя свои табуляции, у меня свои. Не станем их навязывать. Каждый остается при своем, а чтобы оставаться было удобней, умные люди придумали обрабатывающие скрипты (hooks) на события в системах контроля версий.
Я рад, что у вас свои табуляции, но в нашем проекте есть стандарты кодирования и вы должны их соблюдать. Можете хоть хуки настроить, хоть индуса нанять, но все коммиты в проект должны идти в одном стиле.
* код в репозитории хранится с отступами, кратными 4 пробелам
* каждые 8 пробелов обязательно заменяются символом табуляции ASCII 0x09
И где-нибудь код от такого ужаса обязательно поедет
3. В первой версии поста количество матюков достигало трех штук на предложение. Скрепя сердце, матюки повыбрасывал. А то программист нынче пошел нежный, от табуляций и пробелов бледнеет и чахнет, куда ему крепкую лексику. Тут смайл.
Все весело похоливарили, и только Вы восприняли всё это так близко к сердцу, что написали топик, с трудом удержались от матов, пообещали позвать маму и т.д.)
Ну и, кака я уже сказал, топик, в целом, сумбурен. Не понятен ни смысл, ни цель, ни идея.
Не понятен ни смысл, ни цель, ни идея
Смысл, цель и идея топика, на мой взгляд, заключается в том, что проблема «табы или пробелы» является слишком раздутой и по большей части надуманной. О чём, собственно, и попытался поведать нам автор.
И пора завязывать решать несуществующие проблемы вместо того, чтобы наконец-то решать РЕАЛЬНЫЕ задачи.
Лично я всё понял именно так.
А какие реальные проблемы и как их решать? Поехать на Фукусиму с лопатой и убирать последствия катастрофы? Или по трупам пробираться вверх, и, в игоге, стать президентом мира, убив всех плохих человеков?
То, что происходит обсуждение табуляций и пробелов не означает, что паралельно не делается дело.
И да, вы сейчас опять же решаете «несуществующие проблемы вместо того, чтобы наконец-то решать РЕАЛЬНЫЕ задачи».
И да, кричать «не занимайтесь фигней» — прикольно. А чем заниматься? Поведете людей на праведное дело?
То, что происходит обсуждение табуляций и пробелов не означает, что паралельно не делается дело.
И да, вы сейчас опять же решаете «несуществующие проблемы вместо того, чтобы наконец-то решать РЕАЛЬНЫЕ задачи».
И да, кричать «не занимайтесь фигней» — прикольно. А чем заниматься? Поведете людей на праведное дело?
А какие реальные проблемы и как их решать?Под «реальными проблемами» я подразумевал, собственно, решение конкретных рабочих задач вместо того, чтобы заниматься нытьём и рассказывать руководству что-то типа «я не перевариваю табы\пробелы и мне нужна неделя времени на то, чтобы перекроить существующие исходники так, как МНЕ будет понятно»
И да, вы сейчас опять же решаете «несуществующие проблемы...»Я сейчас в своё удовольствие дискутирую на данную тему, которая мне не безразлична. И я целиком и полностью согласен с автором. Если внезапно ко мне придёт работать кто-то, для кого будет проблемой чужие табы или пробелы — то он у меня работать не будет, пускай он будет трижды мега-гуру. Вот и всё.
мне нужна неделя времени на то, чтобы перекроить существующие исходники так, как МНЕ будет понятно»
В любой ИДЕ табы меняются на пробелы и обратно за 5 минут ;)
Да и руководство тут ни при чём. Вопрос «табы или пробелы» стоит только перед тем, кто начинает новый проект или рефакторит проект, в котором не было стиля (при условии, что такой вопрос уже не решен на уровне языка).
Более того, я предлагаю решение этого вопроса. Железобетонное.
Какое?
Читайте «Ответ на главный вопрос»:
1. Придумайте уже какое-нибудь решение по поводу пробелов и табов в файле.
2. Обеспечьте его commit-hook'ом в репозитории.
3. Если кто-то предпочитает другое решение, пусть обеспечивает его сам при выгрузке кода.
1. Придумайте уже какое-нибудь решение по поводу пробелов и табов в файле.
2. Обеспечьте его commit-hook'ом в репозитории.
3. Если кто-то предпочитает другое решение, пусть обеспечивает его сам при выгрузке кода.
О какой проблеме вы говорите? У вас проблемы с редактором? Я могу вам посоветовать хорошую IDE.
Даже в цитате указано, какой IDE я пользуюсь :)
А проблема в том, что программисты жалуются друг другу и друг на друга — на предмет того, кто какие пробельные символы коммитит.
Я рад, что у вас свои табуляции, но в нашем проекте есть стандарты кодирования и вы должны их соблюдать … все коммиты в проект должны идти в одном стиле.
Хм. А я про что?
И где-нибудь код от такого ужаса обязательно поедет
Где поедет? В чьем-то редакторе? Опять же, а я про что пишу?
Не понятен ни смысл, ни цель, ни идея.
Ну извините :)
Даже в цитате указано, какой IDE я пользуюсь :)
Я заметил и, простите, ею не пользовался. Могу посоветовать IDE без проблем
Хм. А я про что?
Не знаю. Мне показалось, что о том, что «У тебя свои табуляции, у меня свои».
Где поедет? В чьем-то редакторе? Опять же, а я про что пишу?
Где-то. Вы предлагаете в одном месте использовать паралельно табы и пробелы. Оно будет ехать при неправильном размере табов, при вставке кода на форуме и т.д.
Опять же, а я про что пишу?
Опять же, я так и не понял, о чём вы пишете.
Ну извините :)
Та без проблем, не нервничайте из-за этого, когда-то извиню))
Я заметил и, простите, ею не пользовался. Могу посоветовать IDE без проблем
Разве я сказал, что у меня проблемы с Komodo Edit?
все коммиты в проект должны идти в одном стиле.Хм. А я про что?
Стоп. Вы не топик дочитали до конца?
Да ну, прямо-таки путаются. Лично я всё чётко понял и солидарен с автором, так что…
Это просто великолепнейший стиль написания статьи. Огромное вам спасибо за отличное настроение на весь день.
Кстати, полностью с вами согласен, пожалуй, лучший способ решить проблему стиля написания кода: там где можешь — используй то, что тебе удобно, там где нужно — используй то, что сказано, и когда нужно — превращай одно в другое.
Кстати, полностью с вами согласен, пожалуй, лучший способ решить проблему стиля написания кода: там где можешь — используй то, что тебе удобно, там где нужно — используй то, что сказано, и когда нужно — превращай одно в другое.
Ух ты, наконец-то я узнал еще одного человека, кто тоже пишет в Komodo!
А чем лишний LF в конце файла не угодил?
Просто пример, не более.
Например, шаблонизатор в php на основе eval или подобный.
В PHP файлах в таких случаях обязательно надо ставить в конце "?>" (тоесть открытый <?php без закрывающего выдаёт ошибку).
Да, я понимаю что все советуют не писать "?>" в конце, а прямо сейчас взять и переделелать чьё-то где-то ядро, чтобы не было eval, чтобы include был и так далее. Вопрос далеко не в этом. А в том, что лишний \n в конце файла вернёт лишний символ в выдачу, а это уже гораздо страшнее.
В таких случаях тупо невозможно создать файл, который открывается на <?php и закрывается на ?>. Чем не пример? Многие редакторы не вставляют то, чего не просят. Некоторые редакторы считают себя умнее.
Простейший пример — берём древний сайт, созданный давным давно, и перносим его на другой хостинг. Делали не мы, исправлять не нам. Открываем config.php, меняем пароль от БД, сохраняем, сайт начинает сыпать ошибками заголовков (Headers already send).
Материмся и ищем, кто виноват (IDE святой, его руками не трогать, ведь у нас есть универсальный аргумент у меня всё работает, я уже три года на нём пишу!).
Например, шаблонизатор в php на основе eval или подобный.
В PHP файлах в таких случаях обязательно надо ставить в конце "?>" (тоесть открытый <?php без закрывающего выдаёт ошибку).
Да, я понимаю что все советуют не писать "?>" в конце, а прямо сейчас взять и переделелать чьё-то где-то ядро, чтобы не было eval, чтобы include был и так далее. Вопрос далеко не в этом. А в том, что лишний \n в конце файла вернёт лишний символ в выдачу, а это уже гораздо страшнее.
В таких случаях тупо невозможно создать файл, который открывается на <?php и закрывается на ?>. Чем не пример? Многие редакторы не вставляют то, чего не просят. Некоторые редакторы считают себя умнее.
Простейший пример — берём древний сайт, созданный давным давно, и перносим его на другой хостинг. Делали не мы, исправлять не нам. Открываем config.php, меняем пароль от БД, сохраняем, сайт начинает сыпать ошибками заголовков (Headers already send).
Материмся и ищем, кто виноват (IDE святой, его руками не трогать, ведь у нас есть универсальный аргумент у меня всё работает, я уже три года на нём пишу!).
Да ничем. Есть не просит, может жить. Но если уж чистить всё, так зачем их оставлять?
Еесть подозрения, что писал я почти о том же самом (тыц) вот только уложился в пяток приложений, да и яснее как-то излагал, правда без пафосу =)
PS: есть одно большое но! Действительно правильный хороший форматёр-преобразователь из одного стиля написания в другой — это очень сложно. И без полноценного анализатора ЯП тут не обойтись. А ведь «холивар» о пробелах и табуляции — это лишь малая часть проблем со стилем при коллективной разработки. Это хорошо, когда в сообществе/команде есть принятые нормы написания кода (как в Rails, например. А вот в Node.JS — ещё нет — надо разрабатывать =) ). Но, увы, иногда обнаруживаются исключения, благо их всё меньше — и это радует.
PS: есть одно большое но! Действительно правильный хороший форматёр-преобразователь из одного стиля написания в другой — это очень сложно. И без полноценного анализатора ЯП тут не обойтись. А ведь «холивар» о пробелах и табуляции — это лишь малая часть проблем со стилем при коллективной разработки. Это хорошо, когда в сообществе/команде есть принятые нормы написания кода (как в Rails, например. А вот в Node.JS — ещё нет — надо разрабатывать =) ). Но, увы, иногда обнаруживаются исключения, благо их всё меньше — и это радует.
Вы именно об этом и писали. И я с вами обоими согласен на все 100%.
Ага. Все так и есть. Хорошо у вас в конторе :)
И да, переформатирование стиля — задача о-о-очень непростая. Полноценный парсер — это обязательно, и это меньшая часть задачи (парсер готовый от компилятора можно взять). А дальше еще миллион дел с теми же самыми выравниваниями, будь они не ладны. Потому и хороших форматтеров мало.
И да, переформатирование стиля — задача о-о-очень непростая. Полноценный парсер — это обязательно, и это меньшая часть задачи (парсер готовый от компилятора можно взять). А дальше еще миллион дел с теми же самыми выравниваниями, будь они не ладны. Потому и хороших форматтеров мало.
Чувствуется наболело. Сложно сказать какой язык использует автор, к счастью современные Ява IDE уже настолько умные что давно захватили человечество и я не слышал про проблемы с пробелами/табами уже лет так десять. Зато всех девелоперов которые запускают авто формат кода перед комитом, мы позорим и критикуем.
В общем действительно автор прав — пробелема есть у кого-то и есть, то это его проблема.
В общем действительно автор прав — пробелема есть у кого-то и есть, то это его проблема.
Автоформат усложняет сравнение версий (особенно для больших файлов), но однозначно упрощает чтение. Так что… не совсем понятно за что позорить, особенно если автоформат использовали и перед прошлым выкладыванием.
Язык здесь не важен.
А за что позорите-то? Просто потому, что сам изначально не пишет аккуратно? Ну так если неаккуратности свои не коммитит, то вроде грех небольшой.
А за что позорите-то? Просто потому, что сам изначально не пишет аккуратно? Ну так если неаккуратности свои не коммитит, то вроде грех небольшой.
язык важен в том плане, что IDE для разных языков существенно по разному развиты. Я всегда говорю — используя для разработки IDE отличную от IDEA или Eclipse вы воруете деньги фирмы (если вы не мега крутой чел который может делать все поперек и все равно будет получаться ОК).
позорим как раз за то, что если чел комитит не авто форматированный код, то потом человек который комити за ним и применяет стандартный стиль автоформатированием — получает кучу якобы изменений которые он не делал.
позорим как раз за то, что если чел комитит не авто форматированный код, то потом человек который комити за ним и применяет стандартный стиль автоформатированием — получает кучу якобы изменений которые он не делал.
Есть же множество прекрасных тем для холиваров:… IE или FF ...
Какая толстая у Вас ирония
Смачно написано. Спасибо. Автор, пиши ещё :)
- код в репозитории хранится с отступами, кратными 4 пробелам
- каждые 8 пробелов обязательно заменяются символом табуляции ASCII 0x09
Лицоруканога.гиф
вся проблема тут в нетерпимости к чужому коду. каждый хочет, чтобы остальные писали код также как он сам. а необходимость читать в чужом стиле вызывает жуткий баттхёрт, куда уж там писать. и пресловутые стайлгайды — не решение. это лишь формализованное «старший разработчик привык так кодить, поэтому все ОБЯЗАНЫ соблюдать этот стиль». а при использовании хуков как сказано в статье — тому разработчику, который протолкнул свой стиль кодирования, никакие хуки настраивать не нужно будет, а вот всем остальным — извольте повозиться. самое страшное — когда в угоду стайл-гайдам жертвуется читабельность и слабосвязность строк кода (когда можно добавить/удалить строчку кода, не изменяя соседние — крайне полезно при слиянии).
да, и диффы без учёта пробелов — опасная вещь, особенно в языках с лесенкой }},},}}
да, и диффы без учёта пробелов — опасная вещь, особенно в языках с лесенкой }},},}}
А нетерпимость следствие наличия оформления в том, что должно описывать только логику. Я вот наконец оформил свою мысль
Какой-то бессмысленный пост, вы уж извините. Проблема между TAB и SPACE существует, а вы тут пишете про какую-то сложную специфику VIMа или чего там еще.
Угу, у нас в конторе тоже пытаются прикопаться к пробелам, причем очень не системно (где-то они хорошо, где-то плохо, где-то это якобы не пробел)
самый приятный и разумный пост за последнее время на Хабре. радует грамотность автора, потому что многие думают, что «скрепя сердце» пишется через «и». Чёрт, приятно, что в Киеве так хорошо знают русский.
хоть из поста ничего не понял, скажу просто Спасибо большое за него.
хоть из поста ничего не понял, скажу просто Спасибо большое за него.
Более того, некоторые пишут «скрипя сердцем», новая идиома, ептыть.
Дык — так и есть: «укрепив сердце, ...»
proof
proof
> Есть, скажем, такой спецэффект в vim'е: если между двумя строками с отступом затесалась одна совсем пустая строка (то есть в файле на ее месте два \n подряд), то vim не сохранял позицию курсора при перемещении вниз-вверх.
Ни разу не замечал. Сейчас проверил — спецэффекта нет. Наверно это было очень давно.
> Теперь в vim пишешь ты (а я в Komodo Edit), но почему-то это осталось моей проблемой. Почему? Потому что vim православнее? Вот не надо. В конце концов, я старше и у меня ноги грязнее. У нас субординация и выслуга лет.
Есть одна (международная) фирмочка в которой есть один сотрудничек с общим числом (не только непосредственных) подчинённых около пятидесяти. Пишет в vim. :P
Ни разу не замечал. Сейчас проверил — спецэффекта нет. Наверно это было очень давно.
> Теперь в vim пишешь ты (а я в Komodo Edit), но почему-то это осталось моей проблемой. Почему? Потому что vim православнее? Вот не надо. В конце концов, я старше и у меня ноги грязнее. У нас субординация и выслуга лет.
Есть одна (международная) фирмочка в которой есть один сотрудничек с общим числом (не только непосредственных) подчинённых около пятидесяти. Пишет в vim. :P
написать фильтр, превращающий любой текстовый файл в излюбленную кандидатом комбинацию пробельных символов для отступов. Не справился за 20 минут?
Синтаксический анализатор за 20 минут? :)
Ну шо вы такое говорите, зачем парсер для того, чтобы причесать пробелы и табы в каждой строчке? Исключительно регулярками можно.
И даже программировать не обязательно. В консоли
И даже программировать не обязательно. В консоли
expand / unexpand.Регулярки корректно обрабатывающие все возможные сочетания кода, комментариев, строк, случаи встраивания кода (как PHP) и т. п.? Возможно, конечно, но за 20 минут не факт, что успеет каждый бы, кто устроил по другим критериям. Про
и т. п. вообще молчу :)
if (...) {
...
}
if (...)
{
...
}
if (...)
{
...
}
и т. п. вообще молчу :)
Шарп, например, имеет контекстно-свободную лексическую грамматику. Это более широкий класс нежели регулярные грамматики. На регулярках там даже токенизацию нормально выполнить нельзя, какой уж там анализатор отступов и пробелов.
man expand
Какая к чертям токенизация? Того, что я хочу, не сделать за 20 минут?
Какая к чертям токенизация? Того, что я хочу, не сделать за 20 минут?
Этот вариант работает лишь для текстовых файлов, которые правильно (согласно «вашей религии и предпочтениям») разбиты по крайней мере на строки. А это уже не «любой текстовый файл» — вспомните хотя бы холивары с "{".
Полноценное форматирование — не сделать. Либо я неправильно понял вашу задачу, что вполне вероятно и о чем я написал выше.
Согласен, то же самое для Java/C++ — да поможет Бог тому кто твердо решит описать регулярками всевозможные больные сочетания строковых литералов и комментариев, которые могут присутствовать в коде.
Эта проблема решается очень просто. Всем программистам при приёме в команду отдаётся документ на изучение с описанием стиля кодирования, принятого в команде. Членам команды намного легче примирится с любым стилем кодирования, если этот стиль был представлен им заранее, а не после пары чекинов написанного ими кода через замечания от тим-лида.
Если у вас нет стиля кодирования в команде, напишите его. И не берите чужой документ, а напишите свой, полностью учитывающий особенности вашего проекта, иначе членами команды это будет трактоваться как навязывание понравившегося лично вам стиля.
Если у вас нет стиля кодирования в команде, напишите его. И не берите чужой документ, а напишите свой, полностью учитывающий особенности вашего проекта, иначе членами команды это будет трактоваться как навязывание понравившегося лично вам стиля.
Что-то я никак не могу нагуглить инструкцию по применению num и count в идентификаторах
В «Совершенном коде» Макконнелла обсуждается этот вопрос. Глава 11.1.
Решается оч просто:
1) Билд менеджер или автомат перед коммитом запускает любой code beautifier, настроенный на style guide проекта.
2) Программер, который не согласен со styleguide после обновления запускает свой.
1) Билд менеджер или автомат перед коммитом запускает любой code beautifier, настроенный на style guide проекта.
2) Программер, который не согласен со styleguide после обновления запускает свой.
Все проще — давно пора уже делать такое IDE, которое хранит код не в виде текста, а сразу в виде синтаксического дерева. Все проблемы whitespace'ов исчезают автоматически :-)
Кстати, IntelliJ уже занялись подобным, сделав MPS.
Вообще-то, такие «IDE» уже давно применяют. Называются компиляторы в объектный код :) ну или в байт-код, или как хотите :)
А по существу — это все классно, но широкого распространения не скоро получит. Раз без IDE отредактировать исходник невозможно, то, скажем, быстренько достучаться к серверу по ssh и поправить ошибку в консоли уже не получится. Уже неудобство.
А по существу — это все классно, но широкого распространения не скоро получит. Раз без IDE отредактировать исходник невозможно, то, скажем, быстренько достучаться к серверу по ssh и поправить ошибку в консоли уже не получится. Уже неудобство.
То, что я предлагаю, находится где-то между байт-кодом и текущим состоянием дел, когда код = текст. Существующие варианты байт-кодов не поддерживают взаимно-однозначное соответствие между синтаксисом и байт-кодом. Я же предлагаю взаимную однозначность для целей разработки. И стандартизацию подобного решения. А тогда уже любая IDE может это реализовать, стандарт-то будет открыт.
emacs, однако.
Может хватит статей про пробелы и табуляцию… Ладно была 1, потом 2-ая, так сейчас 3-ья, мрачная картина складывается. Личное мнение…
> чтобы оставаться было удобней, умные люди придумали обрабатывающие скрипты (hooks) на события в системах контроля версий.
> обязательное задание — написать фильтр, превращающий любой текстовый файл в излюбленную кандидатом комбинацию пробельных символов
> Быстренько гуглим: %твой_любимый язык% tidy. Скачиваем, ставим, прогоняем код через него
> Для %твой_любимый язык% ничего нет? Бери и пиши.
> Пусть Пупкин сегодня же настроит обрабатывающие хуки.
Боже, сколько действий нужно сделать и сколько человек надо анально покарать, чтобы решить «несуществующую» проблему…
А в это время вменяемые люди (тот же Гугол) просто пользуются пробелами.
> обязательное задание — написать фильтр, превращающий любой текстовый файл в излюбленную кандидатом комбинацию пробельных символов
> Быстренько гуглим: %твой_любимый язык% tidy. Скачиваем, ставим, прогоняем код через него
> Для %твой_любимый язык% ничего нет? Бери и пиши.
> Пусть Пупкин сегодня же настроит обрабатывающие хуки.
Боже, сколько действий нужно сделать и сколько человек надо анально покарать, чтобы решить «несуществующую» проблему…
А в это время вменяемые люди (тот же Гугол) просто пользуются пробелами.
предлагаю раскрыть следующие холиварные темы:
— какой отступ должен быть у скобок блока после if/for/while/…
— где должны находиться открывающая скобка?
— отступ return
:-D
— какой отступ должен быть у скобок блока после if/for/while/…
— где должны находиться открывающая скобка?
— отступ return
:-D
появляются развесистые глупые диффы
Btw, нормальные дифферы умеют делать дифф с опциями вида:
— Ignore line ending differences
— Ignore white space length differences
— Ignore all white space differences.
Btw, нормальные дифферы умеют делать дифф с опциями вида:
— Ignore line ending differences
— Ignore white space length differences
— Ignore all white space differences.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пора завязывать