• Рассказ о том, как я майню эфир через meltdown на ваших телефонах при помощи npm
    0
    Если не ошибаюсь, ситуации с такими названиями это ужесточение не покрывает: react-natiue, react-natiive, react-natjve и т.п.
  • Рассказ о том, как я майню эфир через meltdown на ваших телефонах при помощи npm
    0
    Есть такое явление, как «typo-squatting». Можно добавить зависимость на пакет, чьё имя похоже на «оригинальный и полезный пакет». Это вполне может прокатить. Вот реальный пример: habrahabr.ru/company/ruvds/blog/335144
  • Рассказ о том, как я ворую номера кредиток и пароли у посетителей ваших сайтов
    +2
    А как происходит отслеживание открытия средств разработчика?

    Например, так:

    var devtools = /./;
    devtools.toString = function() {
      this.opened = true;
    }
    
    console.log(devtools);
    
    if (devtools.opened === true) {
        alert('Панель разработчика открыта');
    } else {
        alert('Панель разработчика закрыта');
    }
    
  • Управление зависимостями в PHP
    0
    Ясно. Я, в основном всё-таки про отнаследование и переопределение метода говорил и про то, что одним переопределением метода это может не ограничиться, и поддержка этого кода в соответствие с кодом оригинальной библиотеки может требовать больше времени и внимания, чем кажется на первый взгляд.
  • Управление зависимостями в PHP
    0
    Я вас же процитирую:

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

    Ключевые слова здесь: «а с возможностью обновления ошибки будут исправлены вообще без вашего участия».

    Вы ничего про фиксированную версию не говорили в тот момент. Вы говорили про то, что подразумевается возможность обновления. То есть, вы советовали унаследоваться и переопределить метод, а потом спокойно дожидаться, пока придёт обновление. Я просто показываю минусы такого подхода.
  • Управление зависимостями в PHP
    0
    Я на примере кода поясню, что я имел ввиду, потому что мне кажется, что вы уже немного о другом говорите.

    Пример кода
    class ComposerLibDependency {
        public static function usefulMethod($a, $b) {
            return floor($a * $b);
        }
    }
    
    class ComposerLib extends ComposerLibDependency {
        public static function useMoreA($a, $b) {
            return self::usefulMethod($a * 3, $b);
        }
    
        public static function useMoreB($a, $b) {
            return self::usefulMethod($a, $b * 3);
        }
    }
    
    class MyLibPatch extends ComposerLib {
        public static function usefulMethod($a, $b) {
            if (!is_numeric($a) || !is_numeric($b)) {
                throw new Exception('Incorrect input');
            }
    
            return intval(parent::usefulMethod($a, $b));
        }
    }
    
    var_dump(MyLibPatch::useMoreA(2, 3.5));
    var_dump(MyLibPatch::useMoreB(2, 3.5));
    



    Метод MyLibPatch::usefulMethod() здесь в итоге не используется. Чтобы этот мой фикс использовать, нужно заодно переопределить методы useMoreA и useMoreB, по сути, заменяя в них только self на static. Если потом в них придут изменения из ComposerLib, они не отразятся, потому что я эти методы переопределил. Получается, мне нужно будет мониторить внешние зависимости, чтобы в эти переопределённые методы своевременно вносить изменения. Или, даже, если не вносить, то просто удостоверяться, что такое переопределение ничего не ломает в новых версиях билиотеки из композера.

    Это просто к вопросу об отнаследовании.
  • Управление зависимостями в PHP
    0
    Критикал — ни разу в этом году. Из просто ошибок, которыми могу поделиться: этот и этот (плюс пулл-реквест, который приняли) репорты в Yii Framework.

    Из того, всеми деталями чего не могу поделиться: фиксы в cordova-plugin-file-transfer, cordova-plugin-statusbar, react-dom.js (планирую попробовать отправить репорт и фикс, когда появится время, про ReactDOM.render, который возвращает не то, что должен, если вызывается внутри коллбека setState — нужно писать синтетический код для демонстрации — тот, который в проекте используется, показывать не могу), react-select.js (вообще выкинул после пары правок — проще и быстрее оказалось свою обёртку для <select> написать, чем натыкаться на постоянные грабли), sprintf.js (понимает %e, но не понимает %E + ещё несколько моментов, когда она работает не так, как в PHP).

    Просто по поводу криткал-багов у меня такой подход, что проще бывает вообще не использовать библиотеку, чем заниматься правками критикал багов в ней. Поэтому я их не фиксю в других библиотеках и не могу похвалиться подобными правками. Мне хватило одного раза, когда я несколько лет назад работал с ics-parser на его начальных этапах жизни — правда, то, что я фиксил тогда, наружу никуда не выходило. Пишу свою библиотеку на эту тему, но она два года никуда не двигается, и я, наверное, не буду её писать всё-таки.
  • Управление зависимостями в PHP
    0
    Я в моём подходе бремя тестирования беру на себя. Некоторое время назад меня впечатлила книга Г.Майерса «Надёжность программного обеспечения», особенно идея, что тесты нужны для поиска ошибок, а не для того, чтобы просто покрывать ими код или использовать их в качестве двигателя функционала (когда используется TDD). Так что, мне удобнее брать минимально возможное количества кода со стороны, чтобы потом приходилось меньше писать тестов, которые его пытаются сломать.

    Ну и при подходе с композером никто не заставляет ждать цепочку «issue — fix — tag», всегда можете форкнуть и использовать форк до исправления ошибки.

    Минус в том, что форк придётся тоже поддерживать в актуальном состоянии. Нужно будет принимать из оригинала обновления. Иногда эти обновления будут затрагивать лично ваши изменения, не исправляя при этом ошибок, ради которых форк создавался, и придётся делать сложные мёржи.
  • Управление зависимостями в PHP
    0
    Я, собственно, не вас пытаюсь переубедить, а скорее тех, кто прочитает диалог и узнает себя. В своих проектах можно делать как угодно, а рабочие потом придется кому-то поддерживать.

    Я, в общем-то, особенно тоже не убеждаю. Просто я вижу минусы и их озвучиваю. Кто-то видит минусы в моём подходе и тоже их озвучивает. Лично меня такие диалоги хорошо развивают и дают возможность переосмысливать собственные подходы к разработке.

    Просто хорошо, когда есть разные точки зрения, и хорошо, когда видно и минусы и плюсы обеих этих точек зрения. Кто-то (включая меня) может увидеть все эти минусы и плюсы и изобрести третий вариант, который унаследует все плюсы.

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

    Конечно, можно отнаследоваться, но может получиться так, что, например, в классе, от которого я наследуюсь, статичный метод, который я хочу заменить, вызывается как self::method(), а не как static::method(), и в результате вызовы пойдут мимо метода, который я пропатчил в дочернем классе. Придётся тогда и те куски кода тоже в дочернем классе переопределять. А это приведёт к тому, что я больше не буду вызывать часть оригинального кода. Если в эти части придут какие-то изменения, я ими не буду пользоваться, а они могут быть полезными, либо могут как-то значительно влиять на полезность других методов, которые я использую. Мне в таком случае придётся дополнительно следить за кодом, который приходит при обновлениях, чтобы соответственно реагировать в моём дочернем классе. Это снижает ценность подключения и обновления библиотеки в автоматическом режиме — тратится больше времени.
  • Управление зависимостями в PHP
    0
    В том, что я не слежу за развитием библиотеки и вытаскиваю из неё, скажем, 5% кода, который мне реально потребуется, а остальное выкидываю из кодовой базы. А то, что осталось, я дополнительно тестирую самостоятельно. И если вижу ошибки, то я их могу мгновенно исправить, а не отправлять в цепочку: «создать issue на github» → «дождаться фикса» → «загрузить себе через композер», сидя на некорректно работающей библиотеке всё время, пока эта цепочка не завершится.
  • Управление зависимостями в PHP
    0
    При таком подходе, ИМХО, придётся следить за развитием билиотеки в обход композера, потому что иначе можно будет пропустить какое-то обновление безопасности (или просто фикс какой-то ошибки). Это кучу времени будет отнимать.

    Опять же, если вы фиксируете версию библиотеки, это совсем не значит, что её автор в этой версии зафиксировал зависимости от других библиотек на конкретных версиях, и лучше всё-таки регулярно запускать обновления, чтобы приходили обновления зависимостей второго-третьего-далее уровней, которые могут содержать новые уязвимости важные патчи безопасности.

    Лично для меня моя концепция лучше работает. Я её никому не навязываю. Она мне даёт больше плюсов, чем минусов.
  • Зачем я купил Mac Mini (Late 2012) накануне 2018 года?
    0
    Про смысл я не спорил — только хотел поправить по поводу цен на подписку. :)

    Тем более, может быть это пояснение кому-нибудь ещё поможет. Я, когда покупал лицензию, сначала тоже видел корпоративные цены, потому что именно они по-умолчанию открыты, а не цены на персональные лицензии. Из-за этого чуть не начал пользоваться расширенным триалом, потому что 200 долларов в год за IDE — это дороговато всё-таки.
  • Управление зависимостями в PHP
    –3
    У меня иногда бывали моменты, когда в начале проекта корневые неймспейсы часто появляются/удаляются, пока не устаканится какая-то определённая структура. Они, в общем-то, в composer.json прописываются, и чтобы autoload.php и прочие сопутствующие загрузчики перегенерировались, нужно запускать composer update
  • Управление зависимостями в PHP
    0
    если же вы хотите обновляемый пакет

    Я обычно хочу не обновляемый пакет, а надёжный — который с самого начала работал и будет и дальше предсказуемо работать, потому что в нём ничего не поменяется.

    К слову, мой подход приводит к тому, что я иногда в оригинал этого же пакета пулл-реквесты отправляю — из-за того, что внимательно смотрю, что именно принимаю в кодовую базу и как оно работает. По-моему, всем от этого польза. :)

    зачем перекладывать бремя тестирования пакета на себя?

    Это вопрос надёжности ПО. У каждого свои критерии надёжности и того, сколько внимания он готов этому уделять. Есть примеры того, как откровенно вредный код может без вашего ведома подтянуться вместе с зависимостями. В общем-то, чем больше экономишь время, полагаясь на чужой код, который полагается на библиотеку, которая зависит от четвёртой библиотеки, тем выше риск получить нерабочий или уязвимый код.

    Это всё не аксиома, и я не призываю фанатично чему-то следовать. Просто я вижу, что использование зависимостей может помогать тактически, но вредить стратегически.

    Я просто верю, что стремление к надёжному и безопасному коду приводит в компанию людей, которым нужен надёжный и безопасный код, и которые готовы платить больше за твою внимательность в разработке.

    Ну это пока пакет не обновляется а коллеги берут код с FTP

    Я не совсем понимаю, причём тут FTP, если подключаемый код будет лежать в том же самом репозитории VCS. Я всегда считал, что FTP вместе с мамонтами вымер.
  • Управление зависимостями в PHP
    –10
    Лично мне кажется, что copy-paste кода библиотеки лучше работает, чем включение этой библиотеки через Composer. Может быть, я неправильно что-то считаю, но у меня (пример ситуации) выходит так, что использовать код StringHelper из Yii Framework напрямую (удалив из него код, зависимый от HTMLPurifier) выходит выгоднее по времени, чем использование композера. На удаление лишних методов и зависимостей из кода я потрачу один раз несколько минут, и код раз за разом будет нормально работать. Но если я буду что-то включать через Composer, то через какое-то время получится, что на операции обновления зависимостей через него у меня затрачивается больше времени — оно [время] просто накапливается. Сегодня ушло 20 секунд на то, чтобы Composer прочекал все зависимости, завтра ушло ещё 20 секунд. Послезавтра ещё 30 (в новой версии билиотеки, в методе, который я никогда не буду использовать, появилась зависимость от другой библиотеки, которая, конечно же, загрузится и потянет за собой ещё какие-нибудь зависимости). В какой-то момент получится, что я мог потратить с самого начала 2 минуты на copy-paste и удаление ненужного кода, но, в итоге, я потратил за 2 месяца 30 минут только на ожидание, пока композер всё прочекает и обновит. (В итоге, за всю карьеру накапливается куча бесполезно проведённого времени, которое можно было бы потратить гораздо веселее — например, сметнуться в Новую Зеландию за презиками.)

    (Теги, конечно же, не читал, потому что их никто не читает)
  • Ускорение сборки C и C++ проектов
    +3
    Вам нужно было просто продать Macbook Pro и купить Macbook Mini 2012-го года для сборки (памяти на него накатить ещё, и SSD поставить)… Опыт хабрапользователей показывает, что скорость сборки вырастает.
  • Как расправиться с читерами и не переписать весь код
    +1
    Я уточню: имитационный движок — это такая штука, которая работает и на сервере и на клиенте. Клиент отправляет событие и в свой имитационный движок и в имитационный движок на сервере. Имитационный движок на клиенте позволяет видеть прыжок ещё до того, как сервер пришлёт ответ о том, что он изменил какие-то состояния и кому-то разрешил прыгнуть.

    Просто у имитационного движка сервера приоритет выше. И если он прислал информацию, которая отличается от информации в клиенте, то клиент отбрасывает свою информацию и использует то, что прислал сервер.

    По сути, при таком подходе всё превратится в синхронизацию состояний в имитационных движках сервера и клиента, где серверная сторона имеет высший приоритет. И точность синхронизации будет зависеть от того, насколько точно сервер учтёт задержки сигнала, чтобы понять, в какой точно момент времени клиент отправил команду. И если это удалось, то в имитационных движках клиента и сервера события будут протекать одинаково, и когда сервер пришлёт свою версию состояний сцены, на клиенте не придётся вносить никаких изменений, потому что данные о состояниях будут совпадать.
  • Как расправиться с читерами и не переписать весь код
    0
    А в чём именно будет сложность? Я не до конца понимаю. Будет сложно для игроков? Или будет сложно для разработчиков?
  • Как расправиться с читерами и не переписать весь код
    0
    Мне кажется, гораздо проще построить архитектуру таким образом, чтобы клиент занимался только рендерингом и диспатчингом событий. Например, в EVE Online есть имитационный движок Destiny. На серверной стороне постоянно хранятся состояния. Когда игрок выполняет какое-то действие, на сервер отправляется команда (например, переместиться на метр вправо). Эта команда обрабатывается имитационным движком, состояния обновляются, и эти обновления (не вся куча данных сцены, а только обновлённые состояния) рассылаются всем участникам сцены. Далее, клиент делает рендеринг на основании этих состояний. Игрок стреляет — на сервере вычисляется, куда и с каким качеством прилетит его выстрел (на основании текущих состояний в имитационном движке). Ну, и так далее, по такому принципу.

    Просто таким способом вы решите кучу проблем, связанных с читерством игроков. Сейчас же получается, что после решения одной проблемы (уровень урона) у вас появляется другая проблема (телепорты). Потом появится третья проблема, а за ней ещё одна, и так до бесконечности: пока вы доверяете игрокам хоть немного, они будут находить всё новые и новые способы этим доверием воспользоваться. В корне всего лежит именно доверие к игрокам. Оно будет вас принуждать наворачивать кучу кода, каждый кусок которого защищает от определённого типа читерства. В итоге, это всё выродится в монструозную конструкцию, которую будет страшно трогать и которая будет жутко тормозить в плане производительности.

    Если вы избавитесь от лишнего доверия к игрокам, вы сможете сосредоточиться на других более интересных задачах. Например, на оптимизации производительности и новых фичах. Сам архитектурный подход с использованием имитационного движка будет вас защищать от читерства, и вы сэкономите в будущем кучу времени, которое иначе тратили бы на разработку защиты от конкретных его видов.
  • Зачем я купил Mac Mini (Late 2012) накануне 2018 года?
    +1
    Лицензию AppCode нужно будет покупать раз в год и цена первого года $199. Потому будет дешевле $159, а потом совсем дешево — $119.

    Вы немного неправильно понимаете схему лицензий JetBrains. Это цены для компаний. Такой тип лицензии позволяет одному человеку в компании использовать AppCode — без привязки к конкретному человеку.

    Ещё есть тип лицензии «Personal» — человек покупает на своё имя и использует лицензию только для себя. Цены здесь ниже: 89, 71 и 53 доллара.

    При определённых условиях можно получить лицензию бесплатно — нужно заниматься OpenSource. А если есть ящик в домене apache.org, проблем с бесплатной лицензией вообще не будет.

    P.S. Я всё это упомянул потому, что если компания покупает лицензии, то человеку, который собирает всё это железо, будет всё равно на цену лицензии, потому что платить за неё будет не он. Если человек фрилансит и сам оплачивает оборудование и ПО, то он будет использовать personal-лицензию, которая в два раза дешевле.
  • Хороший дизайнер копирует чужие логотипы, великий — крадёт
    0
    Мне кажется, цель у статьи одна — пожаловаться. Об этом сигнализирует одна из меток к статье — та, которая с тремя звёздочками в середине слова. Но оформлено зачётно — акцент смещается с простой жалобы куда-то в другое место. Например, появляется желание сравнивать логотипы из примеров. И не появляется раздражение, которое обычно появляется, когда кто-то использует Хабр в качестве жалобной книги. Это самая интересно написаная жалоба, которую я видел на этом ресурсе (ИМХО, конечно же).
  • Настраиваем интернет шлюз с прозрачным обходом блокировок (а рекламу таки будем блокировать)
    0
    Чтобы он ресолвил зону orion

    Это вы про Drak Net наверное, да? :)
  • Всё плохо: Почему оценка фриланс-биржи Upwork скоро может стать нулевой
    +1
    В это же время T. Rowe Price продолжает урезать инвестиции в свой актив: изначальные $15,8 млн превратились к 2015 году в $10,296 млн. Платформа Elance в январе 2016 года была полностью отключена от вливаний.

    Если кому-нибудь всё ещё интересна эта тема, то к концу 2016-го года совокупная стоимость ценных бумаг Upwork во владении T. Rowe Price снизилась до $8,192 млн. (количество осталось тем же: 1 101 889 — Series A1, 102 917 — Series A2 и 793 184 — Series B1). Так что, за 2016-й год Upwork упала в цене примерно на 13–14% (по сравнению с концом 2015-го).
  • Логирование в Yii 2.0 и PSR-3
    0
    Я вас уверяю, эта подветка комментариев и ваш новый значок не связаны.
  • Логирование в Yii 2.0 и PSR-3
    0
    И этим тратят моё время впустую

    Да и своё собственное тоже.
  • Логирование в Yii 2.0 и PSR-3
    0
    Речь шла о «значимых» проектах, чьи участники принимали участие в формировании стандарта.

    Если речь шла о значимых проектах, для чего вы кидали ссылку на http://sideeffect.kr/popularconvention#php в подтверждение ваших слов про «большинство»?

    И что тогда вы хотели этим сказать? :)

    Я хотел сказать, что из-за невнимательности люди начинают оспаривать слова, которые я не говорил. И этим тратят моё время впустую.
  • Логирование в Yii 2.0 и PSR-3
    –1
    То есть, до конца вы разобрать ситуацию так и не захотели, я правильно понимаю?
  • Логирование в Yii 2.0 и PSR-3
    0
    Но вы же писали, что большинство так писало. Разве не так? Про то, что не нужно всех спрашивать — это уже другая опера. К тому же, если вы перечитаете мои комментарии, я нигде не утверждал, что нужно было спрашивать большинство. Я только озвучил факт, что всенародного голосования не было, и стиль брали из самых известных проектов, что на тот момент давало FIG политические очки.
  • Логирование в Yii 2.0 и PSR-3
    0
    А вы не обратили внимание, что там 64% — это открывающие скобки на той же строке для функций/методов? Получается противоречие с тем, что «Большинство изначально использовало такой стиль». А в случае с классами ситуация близка к 50/50.
  • Логирование в Yii 2.0 и PSR-3
    –1
    Вы, похоже, не до конца поняли ситуацию и не видите, что после этого возникнет дублирование инфромации, которое можно будет безболезненно удалить из текста, упрощая его. :)
  • Логирование в Yii 2.0 и PSR-3
    –1
    Вы, кстати, упустили ещё одну деталь. В первом варианте фигурная скобка иногда пишется на той же самой строке, что и закрывающая круглая для методов/функций (это есть и в PSR-2 и в PSR-12):

    When the argument list is split across multiple lines, the closing parenthesis and opening brace MUST be placed together on their own line with one space between them.

    Так что, случаев больше получается, чем два. А ведь можно было бы всё упростить, если, хотя бы для методов/функций, открывающая фигурная скобка писалась всегда на той же самой строке. Кучу «лишнего кода» ведь можно было бы тогда выкинуть из текста. :)
  • Логирование в Yii 2.0 и PSR-3
    0
    Вы путаете с единообразием

    Если не сложно, поясните, что именно я путаю с единообразием? Я не совсем понял. Я путаю «выглядеть некрасиво», или я путаю «к стандарту», или что-то ещё?

    И все-таки это ну никак не «архитектурная» проблема

    Мне кажется, она похожа на архитектурную проблему. Всё-таки эта проблема касается совокупности факторов. Если бы речь шла просто о том, что нужно или не нужно ставить скобки на отдельной строке, это была бы не архитектурная проблема. Но раз речь идёт о том, что можно единообразно относиться к похожим явлениям, и это единообразие поможет избавиться от избыточных описаний в стандарте, то это больше похоже на архитектурную проблему.
  • Логирование в Yii 2.0 и PSR-3
    0
    Если вы немного внимательнее почитаете мои комментарии, вы увидите, что я нигде не призывал к всенародному голосованию. Я только отметил факт, что его не было.
  • Логирование в Yii 2.0 и PSR-3
    0
    Я не спорю, на какой строке нужно писать скобки. Я просто обратил внимание, что PSR-12 не упрощает вещи, хотя мог бы.
  • Логирование в Yii 2.0 и PSR-3
    0
    Случая всего два

    А мог бы быть один: «всегда та же строка». И это было бы проще, и было бы единообразие.

    Кто пишет анонимки с открывающей скобкой на следующей строке — поднимите руки.

    Добавьте это в стандарт и потихоньку все начнут писать так. Будет выглядеть некрасиво из-за контекста, в котором они обычно используются, но всё равно люди будут подтягиваться к стандарту.
  • Логирование в Yii 2.0 и PSR-3
    0
    По-моему, PSR-12 не упрощает некоторые вещи. И основная архитектурная проблема остаётся на месте: в одних случаях у функций и классов отрывающая фигурная скобка находится на той же самой строке, в других случаях — на следующей. Можно было бы сократить и упростить структуру стандарта, если бы фигурные скобки всегда писались на той же самой строке для классов и функций/методов — вне зависимости от того, анонимные они или нет.
  • Логирование в Yii 2.0 и PSR-3
    0
    Поэтому нельзя сказать, что «большинство изначально использовало такой стиль», если в 16-ти из 22-х крупных проектов фигурные скобки после класса писались на следующей строке. Большинство крупных проектов не равно большинству людей — тех, кто вообще писал код на PHP в тот момент.
  • Логирование в Yii 2.0 и PSR-3
    0
    Дополнительно, вы путаете статистическую выборку из 22-х баз кода с голосованием. Голосование — это когда отдельные люди высказывают мнение. Статистическая выборка — это когда у людей мнение не спрашивают, а просто анализируют что-то уже произошедшее.

    На момент появления PSR-2 эти 22 проекта занимали крупную нишу во всех ±600 миллионах сайтов под PHP. Однако, если брать отдельных людей, которые в тот момент писали на PHP, их будет больше, чем количество людей, которые трудились над этими 22-мя проектами.

    Понимаете мысль?
  • Логирование в Yii 2.0 и PSR-3
    0
    Ну, вы согласны, что стиль был взят из ограниченого количества проектов? Всенародного голосования не было. Учитывалась относительно небольшая база кода и мнение относительно небольшого количества разработчиков.

    Вы писали, что «большинство изначально использовало такой стиль». Я с этим не согласен. Половина использовала один стиль, другая половина – другой. 50–100 разработчиков в крупных проектах — это не большинство программистов на тот момент.
  • Логирование в Yii 2.0 и PSR-3
    0
    Я со своей колокольни вижу, что половина людей такой стиль использовало, а другая половина — нет (мне даже чаще встречался код, где скобки были на той же строке). А со своей колокольни я смотрю где-то с 2002-го года. Текущий стиль летом 2012-го (вместе с PSR-2) пришёл из проектов со знаменитыми именами. В этих проектах, в общем-то, было небольшое количество разработчиков (во всяком случае, точно было небольшое количество разработчиков, которые диктовали стиль кода всем остальным). По сути, текущий вариант пришёл из ограниченного количества проектов, которые были «на слуху». Всенародного голосования не было (за PSR-2 голосовало 18 человек: 13 — за, 4 — против, один — воздержался). Его и не могло быть, потому что FIG нужно было набрать авторитет за счёт причастности к крупным проектам. FIG в тот момент не было популярным. Всенародное голосование оно в тот момент не смогло бы устроить.

    Если бы была возможность выяснить, как пишет большинство разработчкив, ещё неизвестно, что было бы в стандарте, потому что я чаще видел код, в котором фигурные скобки были на той же строке. Ну, просто, такой чаще встречался, чем код, где скобки шли на новой строке. Может быть, мне просто чаще такой код попадался, а на самом деле больше было кода, где скобки шли с новой строки. Лично я видел такую картину.