Им понадобится ещё год работы, что восстановить текущий функционал. Вы можете себе представить браузер, не обновляющийся года?
А последнее серьёзное изменение в Опере было как раз с год назад. Последняя «стабильная» версия падает от каждого чиха. Ещё год Опера в таком состоянии не проживёт — она просто безнадёжно отстанет от реальности. Так что… Надежды нет.
И не надо кликабельными — там кусочек заголовка окна — двойним кликом мыши или правой кнопкой можно изменить режим окна. Собственно в этом 1 пикселе работают все фичи окна операционки.
> Первый в описанных методах часто делает так: govnokod.ru/9614
Вот так? :)
Извините, просто у меня много (ну очень много) претензий к программисту, использовавшему 1й подход :)
Как мне кажется, else-if'ы имеют смысл только при обработке перечисляемых типов (enum), указывающих на тип сущности. И то, неплохо бы это вынести в виртуальные функции или хотя бы ограничиться диспетчеризацией вызовы с помощью switch-case
А вообще, имхо, js здесь не причём, конструкцию else-if можно соорудить где угодно.
Это xml-комментарий для Visual Studio, а не для вас :)
Эти коментарии IDE использует для того, чтобы потом выдать подсказку при автодополнении кода, а так же их используют инструменты для автоматической генерации сопровождающей документации.
А можно пример по поводу повторных багов? Поработаю «адвокатом» )
Вообще, иногда они возникают при правке используемой во многих местах функций. (которых при 2м подходе много, в 1м же их нет). В результате тестеры присылают 2 десятка совершенно одинаковых багов, в том числе и прилепленных к старым не связанным, как повторные.
Я это написал конкретно в защиту 2го программиста на тему объёмов кода. А по поводу измерений проделанной работы объёмом кода — достаточно вспомнить индокод, чтобы всё встало на свои места.
В общем я бы выдвинул такую идею:
Может быть 1й программист легко правит код 2го не потому, что 1й кодит лучше, а потому, что коде 1го сам чёрт ногу сломит.
Ну тут смотря как считать. При первом подхоже объёи кода растёт линейно в зависимости от функционала, а во втором, на повторяющихся тасках, объём кода будет вести себя как sqrt(n) — сначала надо написать обёртки и общие функции, код которых в результате больше, чем если бы вставлять код на место вызовов, но в похожих тасках вызываются уже существующие методы, что значительно уменьшает количество кода.
Наблюдение интересное, но имхо, вывод о причинах неправильный. Всё время работал с языками, подразумивающими строгую типизацию (более или менее — C++, C#, Obj-C), но использую подход 2го программиста, именно потому, что он позволяет избежать множества правок в том месте, где можно было бы обойтись одной, а так же кучи копипасты при появлении нового юрезкейса. И это считается хорошим подходом. А код первого программера, с высокой долей вероятности, я бы отправил на govnokod.ru
Самое печальное, что нет. Наблюдал народ в свитерах в 26°, в результате эпические битвы за кондишку шли. Один товарищ у нас в результате сидел в шортах и футболке (посреди зимы) с персональным вентилятором.
Если у вас есть столько ацетона, то лучше сразу идти с повинной в изготовлении оружия и наркотиков, ибо пластик расстворится не успеет, а ацетон используют при изготовлении наркотиков.
У них есть альтернатива с той же идеологией использования, но не имеющая недостатков pop3 и smtp в реализации? Если нет (а я о такой не слышал, imap, это несколько не то, это не межсерверное), то нафиг, нафиг.
Как минимум XCode такой логике не подчиняется. Он то разворачивается на весь экран с парой строчек кода, то не хочет изменять размер при больших (больше текущего окна) исходниках.
Юзеркейсы в системе немного другие, пожалуй, но каких-то фантастический отличий от Windows нет. И так же вслед за Microsoft пытаются присобачить мобильный интерфейс к системе (только в случае с Apple это iOS)
В общем, радикальных отличий нет. Правда я так и не смог привыкнуть к отсутствию адресной строки в finder'е (файловый менеджер) и каждый раз внезапному поведению кнопки maximize. Собственно, он внезапно может ничего не сделать вообще, логике это не поддаётся.
А последнее серьёзное изменение в Опере было как раз с год назад. Последняя «стабильная» версия падает от каждого чиха. Ещё год Опера в таком состоянии не проживёт — она просто безнадёжно отстанет от реальности. Так что… Надежды нет.
govnokod.ru/9614
Вот так? :)
Извините, просто у меня много (ну очень много) претензий к программисту, использовавшему 1й подход :)
Как мне кажется, else-if'ы имеют смысл только при обработке перечисляемых типов (enum), указывающих на тип сущности. И то, неплохо бы это вынести в виртуальные функции или хотя бы ограничиться диспетчеризацией вызовы с помощью switch-case
А вообще, имхо, js здесь не причём, конструкцию else-if можно соорудить где угодно.
Эти коментарии IDE использует для того, чтобы потом выдать подсказку при автодополнении кода, а так же их используют инструменты для автоматической генерации сопровождающей документации.
Или, не дай бог, вот так: govnokod.ru/9618
Такое с 1й попытки не разгребсти )
Вообще, иногда они возникают при правке используемой во многих местах функций. (которых при 2м подходе много, в 1м же их нет). В результате тестеры присылают 2 десятка совершенно одинаковых багов, в том числе и прилепленных к старым не связанным, как повторные.
Может быть 1й программист легко правит код 2го не потому, что 1й кодит лучше, а потому, что коде 1го сам чёрт ногу сломит.
В общем, радикальных отличий нет. Правда я так и не смог привыкнуть к отсутствию адресной строки в finder'е (файловый менеджер) и каждый раз внезапному поведению кнопки maximize. Собственно, он внезапно может ничего не сделать вообще, логике это не поддаётся.
По крайней мере мы знаем, что в реайтосе он работает )
Задачей было не сравнить с виндой, а посмотреть — что это вообще такое.