Случайный выбор в пределах доверительного интервала придется давать с учетом связей (топографических/географических) на нескольких участках дороги. То есть для 2-х одинаковых пользователей придется дать разный прогноз на целый участок пути. Даже случайный выбор предполагает наличие собственных критериев (хотя бы закон распределения по которому вы будете случайно выбирать из интервала). Мне кажется это уже регулирование.
Пожалуй, что всё же по определению «регулирования» именно так.
Опримальный путь в резултате один, а пользователи по вашей задумке поедут по разным путям. Тоесть часть из них поедут по худшему пути чтобы в целом прогноз выглядил лучше.
Нет, вы сами себе противоречите здесь. Либо у вас есть один оптимальный путь, либо проблема с тем, что из‐за прогноза бывший оптимальный путь более не оптимален.
Если из‐за прогноза какой‐то оптимальный путь должен перестать быть оптимальным, то у вас уже два оптимальных пути: старый и новый. И некоторое приближённое понятие о времени, когда один меняется на другой. Так что всё нормально.
Если доверительный интервал очень широкий, значит прогноз плохой. В противном случае картинка для разных водителей не будет существенно различаться и они выбирут один путь.
Ну так он и будет плохой — из‐за описываемого вами влияния прогноза на самого себя при отсутствии информации о уже запрошенных прогнозах (а ещё лучше — информации о том, насколько вероятна поездка каждого пользователя, запрашивавшего прогноз, по каждой из дорог, для которых прогноз есть).
Если проблема есть, то избавиться от неё можно только с помощью регулирования — случайного или намеренного. Если нет — то с доверительным интервалом всё в порядке.
Те водители, что я видел либо не смотрят карту пробок вообще, либо полагаются на навигатор с поправкой на свой опыт (т.е. едут по проложенному маршруту пока не видят смысла ехать иначе). Я, правда, не видел водителей с Яндекс.Навигатором — все почему‐то использовали навигаторы разных производителей со своими программами, а не свой смартфон.
Ваше первое предложение выходит за рамки прогноза. Это уже регулирование до которого пока еще очень далеко. Да и заниматься этим не должна одна частная компания, пусть даже такая хорошая, как Яндекс.
Какое тут регулирование? У нас есть модель, она выдаёт данные с некоторым доверительным интервалом. Теперь мы вместо того, чтобы дать водителю данные из модели, берём случайное значение внутри интервала и даём его. Регулированием это было бы, если бы значение было не случайным. Собственно, во втором случае это именно регулирование.
Второй вариант я не совсем понял. Если я запросил прогноз или построил маршрут, это вовсе не значит, что я туда поеду.
При расчёте это можно учесть. Вы не поедете — кто‐то поедет, и именно по построенному маршруту. Причём чем точнее будет прогноз, тем более вероятна поездка по нему.
Этот вариант только вызывает вопросы с доверием: более точному прогнозу требуется больше данных от всех водителей.
Есть и другой вариант: если прогноз будет выполняться на серверах Яндекса или хотя бы будет возможность отправлять туда данные и получать их обратно, то можно использовать информацию об уже сделанных прогнозах, чтобы поправить результат следующего. Ваш вариант справедлив только при двух условиях: 1. результат прогноза зависит только от данных статистики (рандомизация нарушает это условие), 2. одинаковых у всех пользователей (предложение из этого комментария нарушает это условие).
По-моему, нужно просто сделать результат случайным. Т.е. прогноз, к примеру, выдал, что на данной дороге машины будут двигаться со скоростью 20-50 км/ч. с вероятностью 95%. Так покажем одному человеку 20, другому 50, третьему 40 и т.д. Таким образом у разных людей будут разные оптимальные маршруты при размытом прогнозе (а он будет размыт при большом числе желающих из-за указанной вами проблемы) и хорошие одинаковые оптимальные маршруты на время, когда дороги недостаточно загружены.
Я считаю, что если вам не нужно вставить в подпись дополнительные контакты, то вставлять туда имя не нужно тем более: оно уже есть в служебных заголовках. Во всяком случае, оно должно быть там, если вы не поленились настроить почтовую программу (или, конечно, сделать соответствующие настройки в Web‐интерфейсе).
С 99 % вероятностью вы не пишете e-mail через дефис, как не делаю этого я. U+002D — это дефисоминус (HYPHEN-MINUS), а не дефис. Дефис — это U+2010. Сравните:
e-mail (HYPHEN-MINUS)
e‐mail (HYPHEN)
. Через дефис пишут только люди, помешанные на типографике.
Самое плохое — это когда смайлики картинкой. Не видел ни одного варианта, который бы не делал строку выше (в pidgin’е, насколько я помню, они одно время имели высоту в три строки (может, правда, и сейчас так)). Поэтому везде, где я могу отключить показ смайликов или превращение их в картинки я отключаю. К счастью, в почтовых программах до автоматической замены текстовых смайлов на картинки пока не додумались.
Наличие вставок вида «я освоил автоповтор символов и на радостях теперь держу „<S-9>“ по минуте на каждом сообщении» заставляет воспринимать отправителя как придурка (если только я его уже не знаю). По этой причине сообщений с множеством смайлов я фактически не вижу — такие вещи вызывают исключение адресата из круга общения. А те, с кем я общаться обязан, таких дурных привычек не демострируют. Набить же «:-):-):-):-):-):-):-):-):-):-):-)» не так легко, поэтому за пределами IM я таких строк не видел вообще.
Но вот что в этом неловкого мне непонятно. Мне не неловко, потому что «плохой» текст пишу не я. Отправителю не неловко, потому что он не считает свой текст «плохим».
Ничего интересного. Для CPython уже давно есть такие декораторы (к примеру, pylibgit), да и значительная (но не бо́льшая) часть популярных библиотек (к примеру, numpy) полностью или частично написаны на компилируемом C или предоставляют доступ (к примеру, PySide/PyQt) к библиотекам на C/C++.
Не у всех и не всегда. Если я пишу код в четыре проекта, то у меня открыто по 1-3 Vim на каждый проект на разных рабочих столах. Плюс если мне надо отредактировать что-то из общих настроек это будет ещё Vim. Я не вижу никакого смысла изменять состояние (в основном, регистры) Vim'ов проектов только чтобы открыть .vimrc, не запуская ещё Vim и ещё меньше смысла в том, чтобы закрывать проекты только затем, чтобы открыть их потом заново.
Ещё я могу открыть отдельный Vim для проверки чего-то (к примеру, своего или чужого ответа на StackOverflow).
Было бы более удивительно, если бы при публикации в хабе Vim этого не произошло. То, что текст стёбный, не означает, что автор прав. Также сложно несерьёзно доказывать неправоту (сложно — но можно, просто не у всех хватит литературных способностей).
Вообще‐то, скорее gq, а не = (последнее должно ограничиваться изменением отступов, от второго можно ожидать и более радикальных изменений вроде добавления египетских скобок). Только надо настроить formatprg или formatexpr.
Замечу, что ограничения не высечены в камне: никто не мешает вам сделать set equalprg=echo\ Foo и наслаждаться заменой всех выравниваемых строк на «Foo» (хотя с intentexpr такое не выйдет). Или просто привязать = к чему‐то ещё. Но от = ожидается только изменение отступов и ничего больше.
Сначала протыкать мышкой в нескольких местах, потом нажать запятую и пробел
протыкать мышкой
Я не могу точно сказать за Sublime, но в Vim вам не нужно использовать мышку. Судя по их сайту, в Sublime тоже не используют мышку для множественных курсоров. Тыкая мышкой, вы физически не успеете за тем, кто редактирует с клавиатуры.
При знании Vim вам без разницы, редактировать таким способом выровненный список на 5 или 500 позиций (но только выровненный; курсоры, судя по всему, этим не ограничены, но сказать, насколько удобно создавать эти курсоры при невыровненном списке я не могу). Попробуйте протыкать список на 500 позиций — скорее всего, вам придётся использовать поиск и замену.
А у вас нет? На странном языке вы, должно быть, пишете. Многокурсорность в Sublime по‐моему применяется тогда же, когда <C-v> в Vim (если после <C-v> вы использовали c или I): для добавления различного стандартного текста (вроде разделительной запятой) в множество мест сразу. Просто многокурсорность гибче. Вас же не смущает огромное количество повторяющихся разделителей, символов присваивания и т.д., с окружающими их пробелами?
Для того, чтобы ругать SVN не обязательно им пользоваться, достаточно услышать, как его ругают. Я вот уже довольно давно убеждён, что с ветвлением в SVN плохо, хотя сам почти им не пользовался. Правда, и в дискуссии на стороне противников SVN обычно не встреваю или говорю только о том, что видел — медленный checkout, ещё более медленный log (при работе с репозиторием, хостящимся не на своей машине и даже не в локальной сети, конечно), нет переписывания истории по запросу клиента (администратор вроде как может, для моих нужд достаточно было просто удалить репозиторий и создать его заново скриптом).
Кстати, в той issue, что вы привели здесь, есть ссылка на shell-command.readthedocs.org/en/latest/index.html. Если вам нужно использовать оболочку, то этот модуль выглядит весьма интересно (он занимается, в том числе, автоматическим экранированием аргументов).
Да ну? Переходите на zsh, всё работает. В fish тоже всё работает. Даже bash можно настроить, чтобы всё работало. Под «всё» я имею ввиду, что повторное нажатие Tab вызывает циклическое переключение между вариантами автодополнения. Zsh дополнительно позволяет управлять переключением стрелками, что очень помогает (как ни странно, у меня нет русской раскладки и все русские тексты я пишу либо со смартфона (транслитом, но используя ruKeyboard), либо транслитом в Vim). Так что я знаю, о чём говорю.
К тому же префикс никак не поможет Таб-ом перейти на нужную папку в консоли, если папок с одинаковым префиксом больше одной =)
Это целиком и полностью вопрос выбора способа создания префикса.
Про библиотеки из C, которые используются как основы для Питоновских библиотек, понятно. Но если уж Питон предоставляет обёртки над функциями из C — можно сделать эти обёртки удобными, как это, собственно, и сделано в большинстве Питоновских библиотек.
Они удобные. Во‐первых, только shell оперирует сплошной строкой: и exec*, и main(), и вещи вроде sys.argv — это всё списки.
Сплошная строка в main()/sys.argv никому на хрен не сдалась и совершенна неудобна: попытайтесь обработать список файлов, полученный в виде сплошной строки и поймёте, почему. Соответственно нелогично иметь сплошную строку на другом конце: это нарушает принцип «явное лучше неявного»: получается «сплошная строка» → «магия» → «список». Вряд ли вы найдёте здесь много человек, способных полностью описать, как работает «магия» в случае с shell: а ведь там это одна из основополагающих вещей.
Собственно, здесь вы нарушаете сразу два принципа: «явное лучше неявного» и «простое лучше сложного». Это не дело.
Сплошная строка небезопасна, так как проще всех посадить на генерацию списков, чем научить всегда использовать экранирование.
Сплошная строка неудобна для генерации списка аргументов из списка вещей (к примеру, файлов) — из‐за экранирования простым ' '.join(argument_list) не обойдётся.
Список удобен для генерации аргументов от и до, и, чёрт возьми, я ни разу, ни в одной своей программе не хотел использовать shell=True или использовать строку. И, по‐моему, нигде и не использую.
Сплошная строка неэкономична: чтобы её создать вам придётся пройти процесс «генерация аргументов» — «экранирование» — «парсинг строки» — «генерация char ** массива». В случае списка половина пунктов из середины выкидывается.
И ещё, если у вас есть функция со списком, то вы можете взять её и прикрутить наверх функцию со строкой, обратное тоже верно. Так зачем тащить в стандартную библиотеку всякую дрянь? Ruby уже имел проблемы с безопасностью от того, что никто не помнит всю документацию (вспомните, к примеру, $ против \Z).
Конечно, вы не можете сделать язык, на котором все программы будут безопасны. Но вы можете уменьшить нагрузку на программиста, уменьшив пространство выбора, оставив только более безопасные решения. В идеологии языка никогда не было TMTOWTDI.
В Python было бы логичнее сделать Popen с *args в качестве списка, чтобы не отличаться от прочих функций, а никак не принимать на вход строку. И отдельный модуль, который позволяет засунуть в *args запуск $SHELL с заданной строкой.
Насчёт однородности — нашёл os.system.
В модуле os много практически прямых привязок к C’шным функциям. И этот вариант использует оболочку. Кроме того, «The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function.» и «Note that POSIX does not specify the meaning of the return value of the C system() function, so the return value of the Python function is system-dependent.»
То есть вы нашли deprecated функцию. Не удивительно, что тут не соблюдается условие однородности: такие функции существуют только для обратной совместимости. По‐моему, её не собираются удалять только потому, что из‐за простоты os.system слишком часто используется.
Более того, однородность между теми же check_output и popen тоже неполная — так почему между моей функцией и вышеперечисленными она должна быть полной?
Мне не жалко повторить во второй раз, что однородность должна быть в библиотеках языка, и что она не идеальна. И, кстати, вы не нашли «что-то, что non-shell и принимает на вход строку». Ну и os.popen* тоже deprecated. Более того, в документации на os.system стоит просто рекомендация использовать subprocess. А в документации на os.popen стоит очень заметное розовое предупреждение о том, что popen «Deprecated since version 2.6». Жаловаться на неоднородность deprecated функций имеет не больше смысла, чем жаловаться на то, что человеческий эмбрион не выглядит как человек: такие неоднородности обусловлены историческими причинами.
Замечу, что в Python 3 ситуация иная: там нет ни deprecation warning при os.popen (но есть рекомендация использовать subprocess), ни информации о том, что с subprocess нужен для замены os.popen в первых абзацах документации этого модуля: здесь написано только то, что subprocess — это замена os.system и os.spawn*. os.popen с цифрами, впрочем, нет вообще.
То же разное поведение subprocess.check_output при shell=True и shell=False — это ли не вопиющий пример неоднородности? Вон, человек тоже недоволен — asvetlov.blogspot.com/2011/03/subprocess.html, плюс там пример вообще неадекватного поведения.
Я с ним согласен. Как я сказал выше, я бы вообще зарубил Popen возможность использовать shell, но добавил модуль или функцию в subprocess, которая сформирует список аргументов для Popen так, чтобы вызывался shell со строкой. Ну и Popen('cat', filename, filename2) выглядит лучше, чем Popen(['cat', filename, filename2]). Но всё это не меняет того факта, что функции в subprocess принимают практически одни и те же аргументы.
Можно использовать Tab. Можно даже помочь пользователю, добавив предсказуемый ASCII-only префикс.
Однородность относится к библиотекам языка. Я просто объяснил, почему вы вряд ли что-либо найдёте. Есть, конечно, и исключения: см. unicode.translate и bytes.translate (тут исключение, вероятно, связана с оптимизацией) или интерфейсы для работы с архивами и потоковыми форматами сжатия (тут исключение, вероятно, связано с разными разработчиками).
Относительно списка: а что бы вы предложили? Учтите, что никому не нужно тратить время на парсинг (если я формирую команду от и до, а не беру из конфига, то у меня нет никаких проблем со списками: наоборот, строки были бы неудобны). Также в *nix есть семейство функций exec*. Они принимают списки: либо в виде char**, либо в виде аргументов: знаете int main(int argc, char **argv) (иногда ещё и с char **env)? Python использует execve, которая использует именно char ** для списка аргументов. Так что хотите-не хотите, а в *nix список вам нужен.
Тем, что это не является необходимым. Программисты любят универсальные решения и конструктивную параною. Если вы избавитесь от русского языка в метках, то получите абсолютно бесполезные имена: если там есть русский язык, то 99% метка написана полностью по-русски. Это не универсально. mount'у абсолютно без разницы, какие байты есть в имени каталога; при использовании простых двойных кавычек и переменных окружения проблемы могут возникнуть только с / и дефисоминусом в начале аргумента. Это не конструктивно.
Фильтруя символы, вы показываете свою неспособность придумать универсальное и корректное решение. Советую просто использовать мой вариант экранировки из первого комментария из Python (+ os.path.abspath и замена /) и двойные кавычки в скриптах.
//
А литературу по этому поводу я не знаю (хотя она должна быть). Но при совместной разработке чего-либо крайне сложно избежать ситуации, когда вам говорят, что это надо переделать «because it is inconsistent with (some previously added code)». Так же откройте некоторые холивары на программистскую тему, там будут постоянно швыряться аргументами про отсутствие однородности: этим грешат противники PHP в PHP vs что-то, эти аргументы можно найти в войнах git vs что-то… Короче, читайте тематические интернеты и понимание этой концепции само придёт к вам.
Нет, вы сами себе противоречите здесь. Либо у вас есть один оптимальный путь, либо проблема с тем, что из‐за прогноза бывший оптимальный путь более не оптимален.
Если из‐за прогноза какой‐то оптимальный путь должен перестать быть оптимальным, то у вас уже два оптимальных пути: старый и новый. И некоторое приближённое понятие о времени, когда один меняется на другой. Так что всё нормально.
Ну так он и будет плохой — из‐за описываемого вами влияния прогноза на самого себя при отсутствии информации о уже запрошенных прогнозах (а ещё лучше — информации о том, насколько вероятна поездка каждого пользователя, запрашивавшего прогноз, по каждой из дорог, для которых прогноз есть).
Если проблема есть, то избавиться от неё можно только с помощью регулирования — случайного или намеренного. Если нет — то с доверительным интервалом всё в порядке.
При расчёте это можно учесть. Вы не поедете — кто‐то поедет, и именно по построенному маршруту. Причём чем точнее будет прогноз, тем более вероятна поездка по нему.
Этот вариант только вызывает вопросы с доверием: более точному прогнозу требуется больше данных от всех водителей.
. Через дефис пишут только люди, помешанные на типографике.
Наличие вставок вида «я освоил автоповтор символов и на радостях теперь держу „<S-9>“ по минуте на каждом сообщении» заставляет воспринимать отправителя как придурка (если только я его уже не знаю). По этой причине сообщений с множеством смайлов я фактически не вижу — такие вещи вызывают исключение адресата из круга общения. А те, с кем я общаться обязан, таких дурных привычек не демострируют. Набить же «:-):-):-):-):-):-):-):-):-):-):-)» не так легко, поэтому за пределами IM я таких строк не видел вообще.
Но вот что в этом неловкого мне непонятно. Мне не неловко, потому что «плохой» текст пишу не я. Отправителю не неловко, потому что он не считает свой текст «плохим».
Ещё я могу открыть отдельный Vim для проверки чего-то (к примеру, своего или чужого ответа на StackOverflow).
Замечу, что ограничения не высечены в камне: никто не мешает вам сделать
set equalprg=echo\ Fooи наслаждаться заменой всех выравниваемых строк на «Foo» (хотя с intentexpr такое не выйдет). Или просто привязать = к чему‐то ещё. Но от = ожидается только изменение отступов и ничего больше.Я не могу точно сказать за Sublime, но в Vim вам не нужно использовать мышку. Судя по их сайту, в Sublime тоже не используют мышку для множественных курсоров. Тыкая мышкой, вы физически не успеете за тем, кто редактирует с клавиатуры.
При знании Vim вам без разницы, редактировать таким способом выровненный список на 5 или 500 позиций (но только выровненный; курсоры, судя по всему, этим не ограничены, но сказать, насколько удобно создавать эти курсоры при невыровненном списке я не могу). Попробуйте протыкать список на 500 позиций — скорее всего, вам придётся использовать поиск и замену.
<C-v>в Vim (если после<C-v>вы использовалиcилиI): для добавления различного стандартного текста (вроде разделительной запятой) в множество мест сразу. Просто многокурсорность гибче. Вас же не смущает огромное количество повторяющихся разделителей, символов присваивания и т.д., с окружающими их пробелами?Это целиком и полностью вопрос выбора способа создания префикса.
Они удобные. Во‐первых, только shell оперирует сплошной строкой: и exec*, и main(), и вещи вроде sys.argv — это всё списки.
Сплошная строка в main()/sys.argv никому на хрен не сдалась и совершенна неудобна: попытайтесь обработать список файлов, полученный в виде сплошной строки и поймёте, почему. Соответственно нелогично иметь сплошную строку на другом конце: это нарушает принцип «явное лучше неявного»: получается «сплошная строка» → «магия» → «список». Вряд ли вы найдёте здесь много человек, способных полностью описать, как работает «магия» в случае с shell: а ведь там это одна из основополагающих вещей.
Собственно, здесь вы нарушаете сразу два принципа: «явное лучше неявного» и «простое лучше сложного». Это не дело.
Сплошная строка небезопасна, так как проще всех посадить на генерацию списков, чем научить всегда использовать экранирование.
Сплошная строка неудобна для генерации списка аргументов из списка вещей (к примеру, файлов) — из‐за экранирования простым
' '.join(argument_list)не обойдётся.Список удобен для генерации аргументов от и до, и, чёрт возьми, я ни разу, ни в одной своей программе не хотел использовать shell=True или использовать строку. И, по‐моему, нигде и не использую.
Сплошная строка неэкономична: чтобы её создать вам придётся пройти процесс «генерация аргументов» — «экранирование» — «парсинг строки» — «генерация char ** массива». В случае списка половина пунктов из середины выкидывается.
И ещё, если у вас есть функция со списком, то вы можете взять её и прикрутить наверх функцию со строкой, обратное тоже верно. Так зачем тащить в стандартную библиотеку всякую дрянь? Ruby уже имел проблемы с безопасностью от того, что никто не помнит всю документацию (вспомните, к примеру,
$против\Z).Конечно, вы не можете сделать язык, на котором все программы будут безопасны. Но вы можете уменьшить нагрузку на программиста, уменьшив пространство выбора, оставив только более безопасные решения. В идеологии языка никогда не было TMTOWTDI.
В Python было бы логичнее сделать Popen с
*argsв качестве списка, чтобы не отличаться от прочих функций, а никак не принимать на вход строку. И отдельный модуль, который позволяет засунуть в*argsзапуск $SHELL с заданной строкой.В модуле os много практически прямых привязок к C’шным функциям. И этот вариант использует оболочку. Кроме того, «The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function.» и «Note that POSIX does not specify the meaning of the return value of the C system() function, so the return value of the Python function is system-dependent.»
То есть вы нашли deprecated функцию. Не удивительно, что тут не соблюдается условие однородности: такие функции существуют только для обратной совместимости. По‐моему, её не собираются удалять только потому, что из‐за простоты os.system слишком часто используется.
Мне не жалко повторить во второй раз, что однородность должна быть в библиотеках языка, и что она не идеальна. И, кстати, вы не нашли «что-то, что non-shell и принимает на вход строку». Ну и os.popen* тоже deprecated. Более того, в документации на
os.systemстоит просто рекомендация использовать subprocess. А в документации наos.popenстоит очень заметное розовое предупреждение о том, что popen «Deprecated since version 2.6». Жаловаться на неоднородность deprecated функций имеет не больше смысла, чем жаловаться на то, что человеческий эмбрион не выглядит как человек: такие неоднородности обусловлены историческими причинами.Замечу, что в Python 3 ситуация иная: там нет ни deprecation warning при os.popen (но есть рекомендация использовать subprocess), ни информации о том, что с subprocess нужен для замены os.popen в первых абзацах документации этого модуля: здесь написано только то, что subprocess — это замена os.system и os.spawn*. os.popen с цифрами, впрочем, нет вообще.
Я с ним согласен. Как я сказал выше, я бы вообще зарубил Popen возможность использовать shell, но добавил модуль или функцию в subprocess, которая сформирует список аргументов для Popen так, чтобы вызывался shell со строкой. Ну и
Popen('cat', filename, filename2)выглядит лучше, чемPopen(['cat', filename, filename2]). Но всё это не меняет того факта, что функции в subprocess принимают практически одни и те же аргументы.Однородность относится к библиотекам языка. Я просто объяснил, почему вы вряд ли что-либо найдёте. Есть, конечно, и исключения: см. unicode.translate и bytes.translate (тут исключение, вероятно, связана с оптимизацией) или интерфейсы для работы с архивами и потоковыми форматами сжатия (тут исключение, вероятно, связано с разными разработчиками).
Относительно списка: а что бы вы предложили? Учтите, что никому не нужно тратить время на парсинг (если я формирую команду от и до, а не беру из конфига, то у меня нет никаких проблем со списками: наоборот, строки были бы неудобны). Также в *nix есть семейство функций exec*. Они принимают списки: либо в виде char**, либо в виде аргументов: знаете int main(int argc, char **argv) (иногда ещё и с char **env)? Python использует execve, которая использует именно char ** для списка аргументов. Так что хотите-не хотите, а в *nix список вам нужен.
Фильтруя символы, вы показываете свою неспособность придумать универсальное и корректное решение. Советую просто использовать мой вариант экранировки из первого комментария из Python (+ os.path.abspath и замена /) и двойные кавычки в скриптах.
//
А литературу по этому поводу я не знаю (хотя она должна быть). Но при совместной разработке чего-либо крайне сложно избежать ситуации, когда вам говорят, что это надо переделать «because it is inconsistent with (some previously added code)». Так же откройте некоторые холивары на программистскую тему, там будут постоянно швыряться аргументами про отсутствие однородности: этим грешат противники PHP в PHP vs что-то, эти аргументы можно найти в войнах git vs что-то… Короче, читайте тематические интернеты и понимание этой концепции само придёт к вам.