Интерпретатору-то плевать, как я буду методы называть (хоть с помощью эмодзи), это все делается для человека.
Но даже если преемник у меня будет - я очень сомневаюсь, что он будет слепо требовать соблюдения PSR-1. В конце концов, ему ничего не помешает автозаменой переименовать методы.
Честно говоря, сомневаюсь, что ему придется лезть в этот код (зачем? метод атомарен, комментарий + параметры строго соответствуют тому, что он делает, тип возвращаемого значения строго определен, метод назван понятно ).
Более того, сомневаюсь, что он вообще будет (хотя и учитываю эту вероятность, все мы смертны).
Подозреваю, что если он появится - он не будет разбираться в моем коде, выкинет на мороз всю кодовую базу от первой до последней строчки и напишет её заново на каком-нибудь ларавеле.
Это мне приходится поддерживать чужое легаси и медленно, очень медленно переписывать его на современный манер.
нейминг методов был в camelCase, а переменных иначе, когда такое встречаешь, это явный запашок легаси и читать довольно больно,
Понимаете, на самом деле всё это - сахар, причем даже не синтаксический :)
Интерпретатору-то плевать, как я буду методы называть (хоть с помощью эмодзи), это все делается для человека. Для моего потенциального преемника.
Поэтому я буду называть методы или поля так, как удобно. Если мне удобно назвать переменную `query_count` - я назову её так. Потому что так удобнее читать, чем queryCount , потому что знак подчеркивания послужит заменой пробелу. Визуальной заменой. Мне в коде будет проще отличить queryCount от queryData. Понимаете?
И, правило с camelCase приходится осознанно нарушать, например, в случае метода по имени getItemsIDSet . Да, для наглядности - get_Items_ID_set гораздо нагляднее, чем слипшиеся буквы разных регистров.
Повторюсь: code style - для людей.
Хорошо бы его соблюдать. Нарушать его - можно, если это сделано определенной целью.
посоветовал отказаться от либы,
Это невозможно. Альтернативы просто нет (есть официальная от разработчиков, но там еще страшнее). Проще переписать либу, тем более она года 3 уже не обновлялась.
Нэйминг - это мягкое. Это соглашения о том, как хорошо бы писать. Потому что мы так договорились, а не потому, что все, кто пишут иначе - ЕРЕТИКИ КОТОРЫХ НУЖНО СЖЕЧЬ.
Строгая типизация - это теплое. Это совсем другое.
либо самописный метод-обертка над PDO
Да, и это не мой метод-обёртка, к сожалению. Глубже, под капотом - библиотека для работы со сфинксом over PDO. И почему, когда для метода в комментарях указано 'returns int' он возвращает что угодно (на самом деле он возвращает array { 0 => count } - я не постигаю.
Напоминаю, из PSR-1:
4.2. Properties
This guide intentionally avoids any recommendation regarding the use of $StudlyCaps, $camelCase, or $under_score property names.
Whatever naming convention is used SHOULD be applied consistently within a reasonable scope. That scope may be vendor-level, package-level, class-level, or method-level.
Обязательное требование к camelCase относится к именам методов.
У меня такого поведения не наблюдается. Ни подчеркивания, ни предупреждения. Только для `$this->count == 0` рекомендуется использовать строгое сравнение.
Это уже меняется... постепенно. Но большое количество легаси-библиотек и странных легаси-решений все еще позволяют выстрелить себе в ногу там, где казалось бы, это невозможно.
Вот один из моих последних таких случаев:
$this->count = $query_count->execute()->fetchNum(); //кол-во строк в результирующем наборе if ($this->count === 0) { throw new Exception('Ничего не найдено. Укажите другие критерии отбора.'); }
Казалось бы, что могло пойти не так? Внезапно, fetchNum() возвращает целое число, а... строку. А я такой губу раскатал, решил строгую типизацию завезти...
-- У меня все сломалось! -- Что именно у вас сломалось? -- Я не знаю, всё! -- Что именно "всё"? -- Я не знаю!!! Что вы на меня кричите? Вы админ вы и чините! -- Объясните пожалуйста, что у вас не работает? -- Уже всё заработало! -- Тогда зачем вы пишете мне? -- Я вам ничего не пишу! Не мешайте работать!
Вы не учитываете один нюанс: это статика. А статика отдается быстро. И это простая статика, строго типизированная - а значит она ещё и показывается быстро.
Яндекс в своей выдаче показывает ваши страницы по своему (точнее по правилам описания страниц). Фактически, ворует ваш траффик, хотя идея то вроде как хороша (для конечного пользователя) - "быстро и прямо из яндекса показать новости". Проблема в том, что это ваши новости.
Год назад получили сообщение от яндекса "Вы генерируете турбо-страницы неправильно и будете отключены".
Я полез в документацию. Я прочитал документацию от корки до корки. Я полностью переписал код генерации турбо-страниц. Тестовые примеры генерации страниц, вставленные в "виджет проверки корректности турбостраниц" выдают "ОК".
Но на странице управления этим делом красным горит надпись "вы генерируете турбо-страницы неправильно и будете отключены".
Да, рядом лежат ссылки "вот вот ваша страница", "вот ваша страница по версии ЯТ". Но, черт возьми, они идентичны с точностью до тега (с учетом задокументированных преобразований)!!!
Более того, код якобы неправильной страницы, вставленной в виджет проверки выдает "ОК, все хорошо".
Я долго переписывался с техподдержкой турбо-страниц. Везде отвечает один и тот же "Платон", но по лексике, набору слов и формулировкам каждый раз это разные люди. И примерно каждый третий из отвечающих теряет нить беседы и начинает отвечать стандартными отписками. Я срываюсь на мат (меня почему-то не посылают в ответ) и на какое-то время помогает. Очередной Платон перечитывает переписку, искренне пытается помочь... и нет.
Прошёл год. Последний ответ техподдержки был таков: "Мы передадим вашу проблему техническим специалистам и они внимательно изучат вашу ситуацию".
Воз и ныне там.
Коллеги восхищаются моим терпением и говорят, что уже давно бы пошли в офис яндекса с топором. Я бы тоже пошёл, но чем виноваты люди, сидящие в офисе на первой линии?
И эти люди ещё считают, что я пишу говнокод и не соблюдаю стандарты. Сами свои стандарты не соблюдают, а еще что-то тявкают!
Бесит.
P.S. Ах да, ещё в какой-то момент техподдержка прямо заявила, что
статус проверки турбо-страниц, выдаваемый на главной странице НЕ СОВПАДАЕТ с внутренним статусом проверки турбо-страниц и обновляется с задержкой. Задержка может быть до НЕДЕЛИ
Вы выдираете слова из контекста. Еще раз:
Но даже если преемник у меня будет - я очень сомневаюсь, что он будет слепо требовать соблюдения PSR-1. В конце концов, ему ничего не помешает автозаменой переименовать методы.
В чем ваша претензия, сударь?
У вас недостаточно информации для суждения, поверьте.
Использовать напрямую PDO можно... но неудобно. Эта переменная - вообще - инстанс Query Builder'а
Честно говоря, сомневаюсь, что ему придется лезть в этот код (зачем? метод атомарен, комментарий + параметры строго соответствуют тому, что он делает, тип возвращаемого значения строго определен, метод назван понятно ).
Более того, сомневаюсь, что он вообще будет (хотя и учитываю эту вероятность, все мы смертны).
Подозреваю, что если он появится - он не будет разбираться в моем коде, выкинет на мороз всю кодовую базу от первой до последней строчки и напишет её заново на каком-нибудь ларавеле.
Это мне приходится поддерживать чужое легаси и медленно, очень медленно переписывать его на современный манер.
Красивый код, IMHO, надо искать в демках 128байт, 4096 байт, 64кб.
Вот там красивый код... по своему.
Совершенно несладкий, но красивый!
Слова ничего не стоят. Просто покажите ваш код.
FORTH? :-)
Чем проще на языке выстрелить себе в ногу - тем нужнее в нём выработанные сообществом правила/рекомендации чистоты кода.
Понимаете, на самом деле всё это - сахар, причем даже не синтаксический :)
Интерпретатору-то плевать, как я буду методы называть (хоть с помощью эмодзи), это все делается для человека. Для моего потенциального преемника.
Поэтому я буду называть методы или поля так, как удобно. Если мне удобно назвать переменную `query_count` - я назову её так. Потому что так удобнее читать, чем
queryCount, потому что знак подчеркивания послужит заменой пробелу. Визуальной заменой. Мне в коде будет проще отличитьqueryCountотqueryData. Понимаете?И, правило с camelCase приходится осознанно нарушать, например, в случае метода по имени
getItemsIDSet. Да, для наглядности -get_Items_ID_setгораздо нагляднее, чем слипшиеся буквы разных регистров.Повторюсь: code style - для людей.
Хорошо бы его соблюдать. Нарушать его - можно, если это сделано определенной целью.
Это невозможно. Альтернативы просто нет (есть официальная от разработчиков, но там еще страшнее). Проще переписать либу, тем более она года 3 уже не обновлялась.
Но - время, время! :(
Вы путаете теплое и мягкое.
Нэйминг - это мягкое. Это соглашения о том, как хорошо бы писать. Потому что мы так договорились, а не потому, что все, кто пишут иначе - ЕРЕТИКИ КОТОРЫХ НУЖНО СЖЕЧЬ.
Строгая типизация - это теплое. Это совсем другое.
Да, и это не мой метод-обёртка, к сожалению. Глубже, под капотом - библиотека для работы со сфинксом over PDO. И почему, когда для метода в комментарях указано 'returns int' он возвращает что угодно (на самом деле он возвращает array { 0 => count } - я не постигаю.
Напоминаю, из PSR-1:
Обязательное требование к camelCase относится к именам методов.
У меня такого поведения не наблюдается. Ни подчеркивания, ни предупреждения. Только для `$this->count == 0` рекомендуется использовать строгое сравнение.
Ну, я послушался. Зря.
Это уже меняется... постепенно. Но большое количество легаси-библиотек и странных легаси-решений все еще позволяют выстрелить себе в ногу там, где казалось бы, это невозможно.
Вот один из моих последних таких случаев:
$this->count = $query_count->execute()->fetchNum(); //кол-во строк в результирующем набореif ($this->count === 0) {
throw new Exception('Ничего не найдено. Укажите другие критерии отбора.');
}
Казалось бы, что могло пойти не так? Внезапно, fetchNum() возвращает целое число, а... строку. А я такой губу раскатал, решил строгую типизацию завезти...
Причем тут яндекс-браузер?
Да, и такое бывает...
Почему это должно быть моей проблемой?
А проблема в том, что я не могу понять, отключили меня или нет.
На одной странице (*) мне говорят "мы вас отключили", а на другой "импортировано 3000 страниц, есть ошибки, если вы не исправите, мы вас отключим".
А на странице статистики вообще 60000 страниц (а должно быть 220 тыс), которые якобы импортированы без ошибок.
И какой из трёх страниц я должен верить?
На этот вопрос техподдержка внятно ответить не в состоянии.
Вторая проблема в том, что я не в состоянии управлять этой херотой ( https://habr.com/ru/post/651573/comments/#comment_24075625 детали)
Есть еще и третья проблема, и четвертая...
(*) админского интерфейса турбо-страниц, забыл как называется эта хрень.
Ну почему же не прижилось... не говорите за весь рынок :)
Вы не учитываете один нюанс: это статика. А статика отдается быстро. И это простая статика, строго типизированная - а значит она ещё и показывается быстро.
Это не так работает.
Яндекс в своей выдаче показывает ваши страницы по своему (точнее по правилам описания страниц). Фактически, ворует ваш траффик, хотя идея то вроде как хороша (для конечного пользователя) - "быстро и прямо из яндекса показать новости". Проблема в том, что это ваши новости.
Подпишусь под каждым словом.
Еще было: "У вас проблемы с обновлением турбо-страниц, потому что каждый раз при запросе к сайту яндекс получает разную RSS-ленту".
У нас, черт возьми, новостной сайт. До 60 статей в час. Какую еще ленту я должен отдавать по запросу яндекса "Отдай мне latest articles" ?
Но нет, якобы я должен отдавать статичные "слепки" каталога статей, которые не должны меняться ни-ког-да. А как отдавать свежие статьи яндексу?
Техподдержка посылает читать документацию.
Не знаешь куда послать клиента? Пошли читать документацию.
Год назад получили сообщение от яндекса "Вы генерируете турбо-страницы неправильно и будете отключены".
Я полез в документацию. Я прочитал документацию от корки до корки. Я полностью переписал код генерации турбо-страниц. Тестовые примеры генерации страниц, вставленные в "виджет проверки корректности турбостраниц" выдают "ОК".
Но на странице управления этим делом красным горит надпись "вы генерируете турбо-страницы неправильно и будете отключены".
Да, рядом лежат ссылки "вот вот ваша страница", "вот ваша страница по версии ЯТ". Но, черт возьми, они идентичны с точностью до тега (с учетом задокументированных преобразований)!!!
Более того, код якобы неправильной страницы, вставленной в виджет проверки выдает "ОК, все хорошо".
Я долго переписывался с техподдержкой турбо-страниц. Везде отвечает один и тот же "Платон", но по лексике, набору слов и формулировкам каждый раз это разные люди. И примерно каждый третий из отвечающих теряет нить беседы и начинает отвечать стандартными отписками. Я срываюсь на мат (меня почему-то не посылают в ответ) и на какое-то время помогает. Очередной Платон перечитывает переписку, искренне пытается помочь... и нет.
Прошёл год. Последний ответ техподдержки был таков: "Мы передадим вашу проблему техническим специалистам и они внимательно изучат вашу ситуацию".
Воз и ныне там.
Коллеги восхищаются моим терпением и говорят, что уже давно бы пошли в офис яндекса с топором. Я бы тоже пошёл, но чем виноваты люди, сидящие в офисе на первой линии?
И эти люди ещё считают, что я пишу говнокод и не соблюдаю стандарты. Сами свои стандарты не соблюдают, а еще что-то тявкают!Бесит.
P.S. Ах да, ещё в какой-то момент техподдержка прямо заявила, что
WTF???