Почему писать по-старинке плохо

  • Почему писать по-старинке плохо

    Антон Долганин 21 Января 2015 10:53 5615
    Пост по следам сегодняшнего поста про D7. В комментариях с Олегом вышел спор, где он доказывал надуманность нового подхода. Отчасти он прав. Вот простой ответ почему лучше приучать себя к новому стилю:

    //наш правильный док.рут 
    echo $_SERVER["DOCUMENT_ROOT"]; 
    
    //тут вставляем компонент новичка, который делает вот что (например, из-за ошибки новичка): 
    $_SERVER["DOCUMENT_ROOT"] = '/newpath'; 
    
    //и вы к нему ниже радостно обращаетесь: 
    echo '<br/>'; 
    echo $_SERVER["DOCUMENT_ROOT"]; 
    
    //а наш "монстро-код" по-прежнему обработал нормально: 
    $context = \Bitrix\Main\Application::getInstance()->getContext(); 
    $server = $context->getServer(); 
    echo '<br/>'; 
    echo $server->getDocumentRoot(); 


    Результат:
    /home/***/www
    /newpath
    /home/***/www
Антон (Scrooge)
21 Января 2015 11:26
Вот тут как-то наглядней, гораздо лучше смотрится, чем в предыдыщем посте)

Но вот эта портянка меня больше всего напугала))
$hlblock = \Bitrix\Highloadblock\HighloadBlockTable::getList(array("filter" => array('TABLE_NAME' => $arOneSKU['USER_TYPE_SETTINGS']['TABLE_NAME'])))->fetch();

Прям в притирочку  :D
2015-01-21_14.07.55.png

Надо какой-то единый стиль принять и использовать, чтоб еще форматтер помогал, а то не все места в форматтере PHPStorm получается настроить, приходится кодить и поправлять...

Когда я изучал ООП, там было написано, что Максимальная длина любой строки PHP-кода не должна превышать 120 символов , а когда познакомился с Битрикс вообще все стало мифом))
Сейчас да, опять надо вспоминать, че там, как там, какой длины.
Я даже CMS свою писал, как многие дураки, на ООП, в самом начале, когда ни капли опыта и вот прошло уже 3 года, так она в душе и живет, зараза))
Алексей
21 Января 2015 17:47
Когда я изучал ООП, там было написано, что Максимальная длина любой строки PHP-кода не должна превышать 120 символов
Ну, во-первых, длина строки к ООП отношения не имеет, во-вторых, это правило придумали, когда больших мониторов еще не было, а в-третьих, никто не мешает разбивать эту строку на читаемые части.
use \Bitrix\Highloadblock\HighloadBlockTable as HL
 
$hlblock = HL::getList([ 
   "filter" => [ 
      'TABLE_NAME' => $arOneSKU['USER_TYPE_SETTINGS']['TABLE_NAME'] 
   ] 
])->fetch(); 
[CODE][/CODE]
Антон Долганин
21 Января 2015 18:14
Я кстати не проникся классами модуля HL-инфоблоков. Не вижу их плюсов (именно классов модуля).
Я делаю так:
- завожу HL-инфоблок (по сути это отдельная таблица)
- под эту таблицу создаю свой D7-класс автоматически (на данном моменте абстрагируюсь уже от HL-модуля)
- и уже со своим классом работаю

Что-то типа такого получается:
\Bitrix\Test\LogTable::waitNextTurn()
(классы складирую в php_interface в данном случае)
Антон (Scrooge)
22 Января 2015 13:52
Ну и что изменилось, у меня монитор 1920 по ширине, 2015 год, ограничитель всегда стоит 120, вы думаете все разработчики сейчас с такими мониторами? Ничего подобного, не о ширине монитора речь.
MIkkie
21 Января 2015 18:11
Пример, про doc_root очень плохой и высосанный из пальца.

//наш крутой разработчик использующий d7
$application = \Bitrix\Main\Application::getInstance()->getContext()->getServer()->set(['DOCUMENT_ROOT' => '/wup-wup']);
echo \Bitrix\Main\Application::getInstance()->getDocumentRoot();
// вывод: /wup-wup
Антон Долганин
21 Января 2015 18:15
Мне кажется, это неправильное поведение системы, и должно быть пофиксено. Я спрошу у разработчиков.
Спасибо за пример!
Антон Долганин
21 Января 2015 18:29
Да, кстати, ваш контр-пример тоже немного натянут :)
Я в посте показал - что мол _может_ случиться ошибка. Не специально так новичок делает.

В вашем случае это целенаправленное изменение системы. Это не случайность.

В любом случае я был бы рад услышать более осмысленный ответ на вопрос сабжа. Мнения разработчиков разнятся везде.
Mikkie
21 Января 2015 19:12
Да мой, пример тоже очень сильно натянут, хотя можно, например, исходить из того, что разработчик ожидает расширение (array_merge) входящего параметра в get метод, а не полного его переопределения.

И да, новый стиль хорошо, однако он еще не в той кондиции, чтобы им реально можно было бы пользоваться. Плюс полное отсутствие Dependency Injection, сводит на нет его реальное использование, постоянно приходится делать пройслойки с помощью других Фреймворков (Речь идет про сложные проекты, а не про сайты взитки или витрины =) ).
Алексей Валеев
22 Января 2015 13:39
Почему-то не могу комментить в блогах разработчиков, поэтому пишу здесь.
Насчет временной отсутствии документации.
В одном из проектов использовались свои таблицы и ORM для доступа к ним. Названия полей таблиц были набраны lowercase'ом, т.к. это банально удобнее маразма битрикса с повсеместным капсом. Все прекрасно работало до одного из обновлений месяц назад, где такие названия полей были запрещены в ядре (дописали strtoupper(field)).
А самое главное, лаконичный ответ техподдержки про ORM: "По сути, это не документированные возможности продукта, и пока они подвержены изменениям."
Антон (Scrooge)
22 Января 2015 14:09
А мне наооборот так нравится,  дело не в Битрикс.
Очень даже красиво, опрятно и понятно даже новичку :)
2015-01-22_17.03.15.png
ivanpanfilov
2 Февраля 2015 10:35
//$_SERVER["DOCUMENT_ROOT"] = '/newpath';

ага,
а если в код добавить удаление папки с битрикс - то система как ни удивительно перестанет работать и D7 тут ничем не поможет  
Антон Долганин
3 Февраля 2015 4:22
В комментариях этот момент обсудили. В частности с MIkkie. Тут не вопрос "нельзя", вопрос вероятности ошибки.
Денис
16 Мая 2016 12:04
А если изменить DOCUMENT_ROOT до подключения ядра?
Антон Долганин
16 Мая 2016 13:18
Например, как в скриптах крона? Да по идее движку какая разница, он то изначально из переменной сервера берет.