Бля, я такой говнокод от таких дебилов видел что это пиздец. Как думаете они проверяют что файл который пришёл из интернета является PDF? Да просто смотрят что  в названии файла у него расширение .pdf (по нормальному это можно проверить по заголовочным байтам в стриме). Просто пиздец. Такой апогей тупости что дивую даёшься. Таких надо блять ссаными тряпками из программирования гнать.

Хз норм

Ну это знать надо чё там откуда читать

Хм, если просто переименуешь файл оно как бе прокатит и примет его как пдф. Ну и байтовую версию можно хакнуть. Просто нужный заголовок записав. Но это сложнее.

++

Какбудто что-то плохое.

Рекламу можно даже игнорировать без адблоков.


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

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

Но вот когда не сайты, а софт с твоей машины чет собирает, тут уже вопросы начинаются.

Прочитал у дядюшки Боба про то, что функции со switch плохие, т.к. делают N действий сразу, нарушают принцип единственной ответственности и принцип открытости/закрытости, между тем, в Rust и функциональных языках задрачивают сопоставление с образом до крови и живут как-то. Кто прав, где можно почитать об этом?

вот я тоже об этом думал



но хотябы функиональные языки умаеют падать при комплияции с ошибкой non exhaustive match

Ну в книге он привёл пример, где в зависимости от варианта перечисления что-то делалось в "плохой" функции со switch. Потом он вынес это всё хозяйство в отдельный интерфейс с реализациями и абстрактной фабрикой, в методе которой уже был switch. Таким образом, можно добавлять новые варианты перечисления, не затрагивая существующий код. Но он забыл (или намеренно не упомянул), что при добавлении нового метода всё-таки придётся менять код.

В красной книге Scala видел табличку примерно следующего содержания:

1) С ООП подходом придётся менять существующий код при добавлении нового метода, с ФП нет;
2) С ООП подходом не придётся менять существующий код при добавлении нового варианта, с ФП придётся.

Ну это ладно, у функций со switch ещё были описаны два недостатка: они большие, и при добавлении новых вариантов будут только увеличиваться, и они нарушают принцип открытости/закрытости.

вот я сегодня буквально втирал людям, про то что плохо пихать логику внутрь свойств в С#

что классі должні біть просто дата классами


И потом в классе генерирующем тестовые данные мне пришлось прописывать связь и в родителе и в ребенке обратную связь


А сделай я умное свойство этот код был бы в одном месте а не во многих


Вот и во прос а как правильно?

так ты получаешь не очевидные ствойства,а так ты получаешь дублирование кода

те-же свитчи это дублирование кода, в отличии от интерфейсов, и шаблона визитер

но не сказл бы что визиторы легки в поддержке

коротче — все говно

Насчёт N действий со switch. Я бы не сказал, что N действий, ведь это всё равно одно действие, если функция адекватно названа и работает на одном уровне абстракции. А с длинными функциями можно бороться как обычно - дроблением на более мелкие.

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