Comments 76
7,9 весьма спорны
остальное достаточно логично
остальное достаточно логично
7 — ударение на «пытаются», то есть слышали, но не знают толком как нужно делать.
notice — не произносится как «нотайс»
10. идиотизм, а не пункт. помните все — теперь нельзя использовать свои шаблонизаторы, посчитают код плохим…
я так понимаю автор перевода верит в те пункты которые он перевел. или не верит? нет мнения автора. :(
я так понимаю автор перевода верит в те пункты которые он перевел. или не верит? нет мнения автора. :(
Сколько примеров проектов со своим шаблонизатором мне приходилось встречать, столько из них так или иначе скатились к дерьмокоду. Но никто же не говорит, что нет исключений из правил ;)
Согласен, шаблонизаторов существует множество, из этого правила следует, что надо пользоваться не своим, но не ясно каким.
Подходит не только для пхп
не понял по поводу SQL и HTML — не совсем согласен.
не поняли или не согласны? или заранее не согласны в стиле «не читал, но осуждаю»?
не понял почему этот довод. Нет вообще объяснений почему.
Не согласен с этим утверждением.
Вообще очень много безпочвенных утверждений — типа так и все.
А я сейчас скажу что, если кодер использует в офрмлении кода 4 символа пробела в «TAB» вместо двух то он говнокодер — что тоже безпочвенно.
Не согласен с этим утверждением.
Вообще очень много безпочвенных утверждений — типа так и все.
А я сейчас скажу что, если кодер использует в офрмлении кода 4 символа пробела в «TAB» вместо двух то он говнокодер — что тоже безпочвенно.
Че тут понимать-то?
Я вот с брезгливостью отношусь к такому коду, где смешано в одном файле и примерно в одном месте 3 языка (хорошо, если 3, а то, бывает, там же еще динамически рисуется javascript функция и формируется комманда для shell). Аргументы:
* подобный код криво выглядит в большинстве редакторов с подсветкой синтаксиса
* код засоряется мусором, необходимым для разделения языков и экранирования: теги, кавычки, бекслеши
* наконец, часто это признак архитектуры «большая помойка»: в той же парадигме MVC SQL — это уровень Model, HTML — View
Все вышеперечисленное неизбежно приводит к затрудненному восприятию кода человеком и способствует возникновению ошибок на ровном месте.
Я вот с брезгливостью отношусь к такому коду, где смешано в одном файле и примерно в одном месте 3 языка (хорошо, если 3, а то, бывает, там же еще динамически рисуется javascript функция и формируется комманда для shell). Аргументы:
* подобный код криво выглядит в большинстве редакторов с подсветкой синтаксиса
* код засоряется мусором, необходимым для разделения языков и экранирования: теги, кавычки, бекслеши
* наконец, часто это признак архитектуры «большая помойка»: в той же парадигме MVC SQL — это уровень Model, HTML — View
Все вышеперечисленное неизбежно приводит к затрудненному восприятию кода человеком и способствует возникновению ошибок на ровном месте.
Не путай горячее с холодным. HTML — это не язык программирования, а разметки. Во-вторых речи не было о трех языках программирования.
Тут основной аргумент — что нельзя легко изменить внешний вид, не трогая код (и наоборот).
Причем часто это должны делать разные люди: программист — править программный код, а верстальщик — HTML, не боясь ничего сломать.
Причем часто это должны делать разные люди: программист — править программный код, а верстальщик — HTML, не боясь ничего сломать.
Какая-же забавная статья. Особенно понравились бредовые пункты 6, 7, 9 и 10.
Интересно, а если мне придеца писать свой собственный шаблонизатор потому как я использую xslt, использовать в приложении по большей части трехуровневую иерархию классов небольшую кучку прекрасных и любимых мною паттернов и все это скинуть в папочку Core, где под третьим пыхом нормально разбить все на компоненты с помощью NS — то судя по этой статье у меня будет тотальный быдлокод?
Интересно, а если мне придеца писать свой собственный шаблонизатор потому как я использую xslt, использовать в приложении по большей части трехуровневую иерархию классов небольшую кучку прекрасных и любимых мною паттернов и все это скинуть в папочку Core, где под третьим пыхом нормально разбить все на компоненты с помощью NS — то судя по этой статье у меня будет тотальный быдлокод?
товарищи, в статье обсуждается общий случай. Если вы в частности сможете избежать быдлокода, даже смешивая HTML с SQL — это же прекрасно.
Но чаще всего таким образом можно распознать студента — первокурсника, который прочитал книжку (или две) по ПХП. А теперь пишет код на продажу.
Обратите внимание, что это несколько _простых_ пунктов оценки качества.
Если, к примеру, вы пришли на небезызвестные биржи фрилансеров с просьбой «написать приложение которое...»? И вы — НЕ разработчик.
Не относитесь так серьезно к себе — это мешает смотреть с разных точек зрения.
Но чаще всего таким образом можно распознать студента — первокурсника, который прочитал книжку (или две) по ПХП. А теперь пишет код на продажу.
Обратите внимание, что это несколько _простых_ пунктов оценки качества.
Если, к примеру, вы пришли на небезызвестные биржи фрилансеров с просьбой «написать приложение которое...»? И вы — НЕ разработчик.
Не относитесь так серьезно к себе — это мешает смотреть с разных точек зрения.
Общий случай — это плохо. Это все та же средняя температура по больнице, и применять к трупам лежащим в морге и пациентам с высокой температурой одни и теже методы для выяснения диагноза — как-то неравильно. У трупа проблематично взять анализы, а от вскрытия живой пациент может и отказаться.
Скажем так, действия этих списков очень плохо виляют на мозг таких вот клиентов, которые после себя мнят очень умными, и точно знают что и как должно быть… Общаться с такими довольно сложно.
Скажем так, действия этих списков очень плохо виляют на мозг таких вот клиентов, которые после себя мнят очень умными, и точно знают что и как должно быть… Общаться с такими довольно сложно.
Пункты 3 и 9 никак не аргументированы автором, при всей их сомнительности.
по моему автор статьи. да и перевода тоже, не программер и «слышал звон, да не знает, где он»
Ваша статья несёт обобщающий смысл, а ведь в каждом случаи могут быть весомые аргументы делать именно так, а не как вы видите правильней. Это всё равно, что судить о работе доктора по недавно прочитанной статье некого другого…
5,6,7,9 спорно
Не занимайся переводом не разбираясь в теме, а так же не оставляя комментариев, когда тема обещает быть конфликтной. Если ты хочешь это опровергенуть, и подтвердить компетентность — расскажи про отличия / преимущества / недостатки использования Sinleton и global.
P. S.
Судя по всей статье ты еще забыл разнести в пух и прах goto.
P. S.
Судя по всей статье ты еще забыл разнести в пух и прах goto.
> не разбираясь в теме
аргументируйте.
> не оставляя комментариев
все-таки не совсем?
> ты хочешь это опровергенуть, и подтвердить компетентность
зачем? перед кем мне подтверждать компетентность? тут уже многие выразили мнение, что ничего плохого если смешать HTML с СSS, может перед ними прочитать лекцию об архитектуре MVC?
аргументируйте.
> не оставляя комментариев
все-таки не совсем?
> ты хочешь это опровергенуть, и подтвердить компетентность
зачем? перед кем мне подтверждать компетентность? тут уже многие выразили мнение, что ничего плохого если смешать HTML с СSS, может перед ними прочитать лекцию об архитектуре MVC?
Подтверждать — перед собой. Была бы компетентна — ты бы даже не посмотрела на эту статью «сенсационную». У MVC — недостатков не меньше чем у лапши из месива php и html, это тоже стоит знать, и понимать когда лапша, а когда MVC, а не двигать темы про высокое искусство-ради-искусства, тогда уже стоило бы привести в качестве дополнительных аргументов что-то типа не покрытия тестами кода.
Единственная проблема PHP, и соответственно приложений на нем — простота.
Единственная проблема PHP, и соответственно приложений на нем — простота.
А мне понравилась статья. Я смотрел достаточно быдлокодовых поделок и встречал в разных проектах абсолютно все вышеперечисленные пункты. Над многими в слух ругался (особенно когда запускаешь на своей девелоп машине с отображением ошибок и вываливается около полутора тысяч предупреждений). Но если поставить перед собой цель раскритиковать статью, то можно зацепиться за любой из пунктов — есть хорошие программы, где проскакивает какой-то из этих признаков.
похоже большинство разделились на группы «не понимаю, но не одобряю», и «понимаю, но сам так писал, поэтому обидно».
А я встречал не быдлокод, где встречались почти все перечисленные пункты. И код этот продаётся в огромных количествах за приличные деньньги.
В исходниках второй версии IPB есть
1) глобальный класс, который знает всё
2) там используются паттерны
3) шаблонизатор вроде бы вообще не используется (не вникал сильно в исходники)
4) папка core или что-то подобное была, если я не ошибаюсь.
Быдлокод по четырём из десяти признаков?
p.s. хотя глобальный класс с точки зрения архитектуры, конечно, не слишком удобен. к третьей версии разработчики от него отошли.
В исходниках второй версии IPB есть
1) глобальный класс, который знает всё
2) там используются паттерны
3) шаблонизатор вроде бы вообще не используется (не вникал сильно в исходники)
4) папка core или что-то подобное была, если я не ошибаюсь.
Быдлокод по четырём из десяти признаков?
p.s. хотя глобальный класс с точки зрения архитектуры, конечно, не слишком удобен. к третьей версии разработчики от него отошли.
1. Создание супер класса ([Ext]Object), и последующее наследование от него всего остального, может помочь при бенчмарке/отладке/сопровождении продукта. Как? Ну например в конструктор и деструктор вносится код, который подсчитывает количество созданых обьектов, может (при необходимости) и ссылки на каждый из них, и т.п.
2. Тут почти согласен. «Почти» потому что, все же, ингода удобнее использовать именно такой способ доступа к глобальным переменным, а может архитектура приложения этого требует. Хорошая архитектура не может такого требовать? А собсно, что для вас хорошая архитектура? У каждого на это свой взгляд, по моему.
3. Примеры перемешаного html и sql:
SELECT * FROM table
INSERT INTO table VALUES ('html ')
выражайтесь более понятно :) Ну а возвращаясь к истинному смыслу этого пункта, то да, согласен, винигрет — не лучший стиль программирования, хотя, это еще не делает этот код говнокодом.
4. Ну вообщето классы мона использовать вместо неймспейсов, а такие классы очень много знают…
5. См. п. 4 (в случае с неймспейсами публичность/непубличность теряет смысл)
6. Если я хочу структиризировать свое приложение, использовать ООП на полную, то почему я должен следовать этому бессмысленному правилу/замечанию? Если у меня Кнопка наследует Компонент, который наследует Контейнер, который наследует Слушателя, который наследует Обьект (это для примера), то это делает мой код говнокодом? Это структуризация, чтон не писать кое-что по несколько раз ;).
7. Снова же структуризация. К тому жепаттерны делают код более понятным. Неправильное использование паттернов? А кто знает единственно правильный способ испозования набора/соотношения паттернов? У каждого свой стиль, и если он не сходится с вашим, это не делает его неправильным.
8. В принципе, нотисы — не ошибки, но отчасти согласен, разработчик должен был посмотреть нотисы и постаратся удовлетворить интерпретатор, но все же, это не критично.
9. Необосновано ничем.
10. Если у меня есть возможность для шаблона использовать только str_replace, то зачем мне монстров подключать?
даж не заметил что так много написал… :)
2. Тут почти согласен. «Почти» потому что, все же, ингода удобнее использовать именно такой способ доступа к глобальным переменным, а может архитектура приложения этого требует. Хорошая архитектура не может такого требовать? А собсно, что для вас хорошая архитектура? У каждого на это свой взгляд, по моему.
3. Примеры перемешаного html и sql:
SELECT * FROM table
INSERT INTO table VALUES ('html ')
выражайтесь более понятно :) Ну а возвращаясь к истинному смыслу этого пункта, то да, согласен, винигрет — не лучший стиль программирования, хотя, это еще не делает этот код говнокодом.
4. Ну вообщето классы мона использовать вместо неймспейсов, а такие классы очень много знают…
5. См. п. 4 (в случае с неймспейсами публичность/непубличность теряет смысл)
6. Если я хочу структиризировать свое приложение, использовать ООП на полную, то почему я должен следовать этому бессмысленному правилу/замечанию? Если у меня Кнопка наследует Компонент, который наследует Контейнер, который наследует Слушателя, который наследует Обьект (это для примера), то это делает мой код говнокодом? Это структуризация, чтон не писать кое-что по несколько раз ;).
7. Снова же структуризация. К тому жепаттерны делают код более понятным. Неправильное использование паттернов? А кто знает единственно правильный способ испозования набора/соотношения паттернов? У каждого свой стиль, и если он не сходится с вашим, это не делает его неправильным.
8. В принципе, нотисы — не ошибки, но отчасти согласен, разработчик должен был посмотреть нотисы и постаратся удовлетворить интерпретатор, но все же, это не критично.
9. Необосновано ничем.
10. Если у меня есть возможность для шаблона использовать только str_replace, то зачем мне монстров подключать?
даж не заметил что так много написал… :)
Примеры к пункте 3 (хабр сьел пробелы, заменю на подчеркивание):
<_b_>SELECT * FROM table<_/b_>
INSERT INTO table VALUES (' <_b_> html <_/b_>')
<_b_>SELECT * FROM table<_/b_>
INSERT INTO table VALUES (' <_b_> html <_/b_>')
Мне кажется что нотисы действительно признак плохого кода.
Если у вас вылазят предупреждения, значит вы где-то просчитались,
что-то забыли или не учли — вперед исправлять. Никаких потом, или пофиг :)
Если у вас вылазят предупреждения, значит вы где-то просчитались,
что-то забыли или не учли — вперед исправлять. Никаких потом, или пофиг :)
вот я во многом не согласен в автором статьи, но
>8. В принципе, нотисы — не ошибки, но отчасти согласен, разработчик должен был посмотреть нотисы и >постаратся удовлетворить интерпретатор, но все же, это не критично.
но в этом не согласен с вами в корне, представьте, у вас 100к — 1кк запросов в сутки, допустим вы клали все время причинное место на нотайсы (мне так больше нравится хотя и не так звучит), что у вас получится? правильно — каша. нотайсов и ворнингов быть не должно по возможности вообще, это факт. иначе поиск текущего нотайса, мешающего нормально жить вашему приложению, может занять очень много времени которое с точки зрения работодателей стоит в общем случае весьма не дешево
>8. В принципе, нотисы — не ошибки, но отчасти согласен, разработчик должен был посмотреть нотисы и >постаратся удовлетворить интерпретатор, но все же, это не критично.
но в этом не согласен с вами в корне, представьте, у вас 100к — 1кк запросов в сутки, допустим вы клали все время причинное место на нотайсы (мне так больше нравится хотя и не так звучит), что у вас получится? правильно — каша. нотайсов и ворнингов быть не должно по возможности вообще, это факт. иначе поиск текущего нотайса, мешающего нормально жить вашему приложению, может занять очень много времени которое с точки зрения работодателей стоит в общем случае весьма не дешево
Слишком, слишком категорично. Наверняка автор прав во многом, но все сводится на нет категоричность. Хороший пример на тему — дурно пахнущий код
категоричность = собственное мнение, или это подмена понятий?
Нет, это не подмена понятий. Когда я написал «категоричность», я имел в виду категоричность, ничего более и ничего менее.
как вам тогда формулировка:
«N. Вероятнее всего, вы столкнулись с не слишком опытным программистом, если нашли в одном из файлов смешанный HTML и SQL. Поскольку так поступают в первую очередь начинающие программисты на PHP, если вы уверены, что ваш программист — не начинающий, этот пункт следует пропустить.»
достаточно политкорректно, думаете не заминусовали бы тогда? ;)
«N. Вероятнее всего, вы столкнулись с не слишком опытным программистом, если нашли в одном из файлов смешанный HTML и SQL. Поскольку так поступают в первую очередь начинающие программисты на PHP, если вы уверены, что ваш программист — не начинающий, этот пункт следует пропустить.»
достаточно политкорректно, думаете не заминусовали бы тогда? ;)
Блин, недостаточно сделать str_replace, чтобы избавиться от категоричности. Категоричность — это когда "
Вот так и никак иначе. Без комментариев. Точка.".
Пути к улучшению:
1. По каждому пункту — внятно — почему так делать не рекомендуется
2. По каждому пункту пример, когда именно так делать необходимо
3. По каждому пункту пример (ссылку) на наиболее вероятное решение проблемы. Иначе говоря, как хотя бы по этому пункту сделать свой код лучше.
Насчет заминусовали — хз, я не знаю рейтинга, еще не голосовал.
Вот так и никак иначе. Без комментариев. Точка.".
Пути к улучшению:
1. По каждому пункту — внятно — почему так делать не рекомендуется
2. По каждому пункту пример, когда именно так делать необходимо
3. По каждому пункту пример (ссылку) на наиболее вероятное решение проблемы. Иначе говоря, как хотя бы по этому пункту сделать свой код лучше.
Насчет заминусовали — хз, я не знаю рейтинга, еще не голосовал.
Спасибо, рекомендации к которым стоит прислушаться. И да, дейстивтельно с категоричностью перебор вышел =).
Начать стоит с изменения названия топика.
Да не парьтесь Вы.
Объяснение тут одно — автору не повезло с фрилансерами, и все написанное суть сухой остаток его личных душевных страданий из-за их кода.
Стали бы по пунктам разъяснять, тут же набежала бы куча местных специалистов по правильным шаблонизаторам и использованию паттернов по фен-шую в PHP и началось бы обчное жевание соплей. А так ничего получилось — капля здорового троллинга :)
Объяснение тут одно — автору не повезло с фрилансерами, и все написанное суть сухой остаток его личных душевных страданий из-за их кода.
Стали бы по пунктам разъяснять, тут же набежала бы куча местных специалистов по правильным шаблонизаторам и использованию паттернов по фен-шую в PHP и началось бы обчное жевание соплей. А так ничего получилось — капля здорового троллинга :)
1. Кстати, куда делся xprogramming.ru ???
2. хочу поправить опечатку, а не могу :(
2. хочу поправить опечатку, а не могу :(
давайте в обратном порядке:
10. тогда это и не шаблонизатор, а использование str_replace. Речь об изобретениях велосипеда.
9. Иногда это неизбежно, и должно называться именно core, но «общая температура по больнице» — до добра это не доведет. Кто-то из разработчиков обязательно неправильно поймет, что должно быть в общей концепции core, кто-то не до конца отдокументирует… Можно считать что это IMHO, но очень часто срабатывает.
8. Руки мыть перед едой тоже не критично ;)
7. О неправильности можно говорить как о неправильном понимании принципов. Используют фабрику там где она никому не нужна, например.
6. Хотите — вперед. Исключения из правил никто не отменял.
5-4. Это считается плохим стилем. Ну уж извините. Все авторы об этом пишут. И все программисты их используют.
3. Это не совсем то что имелось в виду, вы же понимаете ;)
2. >что для вас хорошая архитектура? У каждого на это свой взгляд.
ой-неет, только не надо, тогда каждый студент вас будет до зубной боли убежать что это не убожетсво, а его «архитектурное решение в соответствии с собственным взглядом».
1. См. пункт про исключения.
опять много? )
10. тогда это и не шаблонизатор, а использование str_replace. Речь об изобретениях велосипеда.
9. Иногда это неизбежно, и должно называться именно core, но «общая температура по больнице» — до добра это не доведет. Кто-то из разработчиков обязательно неправильно поймет, что должно быть в общей концепции core, кто-то не до конца отдокументирует… Можно считать что это IMHO, но очень часто срабатывает.
8. Руки мыть перед едой тоже не критично ;)
7. О неправильности можно говорить как о неправильном понимании принципов. Используют фабрику там где она никому не нужна, например.
6. Хотите — вперед. Исключения из правил никто не отменял.
5-4. Это считается плохим стилем. Ну уж извините. Все авторы об этом пишут. И все программисты их используют.
3. Это не совсем то что имелось в виду, вы же понимаете ;)
2. >что для вас хорошая архитектура? У каждого на это свой взгляд.
ой-неет, только не надо, тогда каждый студент вас будет до зубной боли убежать что это не убожетсво, а его «архитектурное решение в соответствии с собственным взглядом».
1. См. пункт про исключения.
опять много? )
На мой взгляд (а я исхожу из того что этот пост позиционируется автором как пост для чайников) ни одно из утверждений абсолютно не аргументировано!
Для человека знающего п.1 выглядит наиболее разумно (но и это утверждение попытался опровергнуть один из коментаторов)… А все остальное очень спорно и должно трактоваться в зависимости от конкретной ситуации.
Лично для себя я сделал вывод, что человек, это написавший или гениальный программист, который ни разу в жизни не делал ни одной ошибки (таких не бывает :) ), или пытается казаться умнее, чем есть на самом деле…
В любом случае не рекомендовал бы ее к прочтению людям, слабо или совсем не разбирающимся в предмете…
Для человека знающего п.1 выглядит наиболее разумно (но и это утверждение попытался опровергнуть один из коментаторов)… А все остальное очень спорно и должно трактоваться в зависимости от конкретной ситуации.
Лично для себя я сделал вывод, что человек, это написавший или гениальный программист, который ни разу в жизни не делал ни одной ошибки (таких не бывает :) ), или пытается казаться умнее, чем есть на самом деле…
В любом случае не рекомендовал бы ее к прочтению людям, слабо или совсем не разбирающимся в предмете…
А я понял, что плохого в 9-ом пункте!
Папка должна называться не core, а std!
Папка должна называться не core, а std!
Излагаю краткое содержание статьи:
>> если вы нашли слово php в коде приложения,
>> то код его однозначно говно.
>> если вы нашли слово php в коде приложения,
>> то код его однозначно говно.
Ненавижу Регину Дубовицкую;
Храню все общие для сайтов (у меня мульти-сайтовый движок) классы, хелперы, и прочие нужные штуки в папке core;
Использую свой темплейтер с нативным php (вернее основной часто-используемый драйвер. Темплейлер я могу подключить любой).
Перестал дерьмо-кодить 2 года назад.
Переводчик, что-то не так о.О?
Храню все общие для сайтов (у меня мульти-сайтовый движок) классы, хелперы, и прочие нужные штуки в папке core;
Использую свой темплейтер с нативным php (вернее основной часто-используемый драйвер. Темплейлер я могу подключить любой).
Перестал дерьмо-кодить 2 года назад.
Переводчик, что-то не так о.О?
Напомнило стиль Лебедева… Ему тоже в любой компании везде мерещатся 95% мудаков, и 5%, способных лизать задницу начальству.
Аргументируйте по пунктам хотя бы…
Аргументируйте по пунктам хотя бы…
Большая часть пунктов косвенные признаки, для какойто типичной именно для автора задачи. Массив GLOBALS часто бывает уместен но это зависит от условий его использования и нельзя просто изза егоналичия говорить что код плохой
С утра прочитал ещё раз признаки, и охренел. Хорошая постановка совета заказчику —
То есть приношу я заказчику код скрипта ночами писанный, трудный, с применением всяких фичек — а он мне такой — «Ну ка ща проверим твой код!». Нажимает Ctrl+F, вводит global. Находит его в куске кода —
Всё? Я попался? Теперь заказчик не примет мою работу, аргументируя тем, что на авторитетном ресурсе Хабр бравый защитник нашихбаранов заказчиков расписал все от и до — и мой скрипт — о ужас — просто быдлокод.
Утрирую конечно…
2. Код использует пользовательские глобальные переменные.
Поиск по коду слов «global» или "$GLOBALS" может открыть Вам много интересного, например такого:
global $database, $my, $mainframe;
Если вы сможете мне сказать, что содержится в последних двух переменных, вы либо близко знакомы с автором строк программы, откуда взят этот пример, либо псих. Вероятность второго варианта увеличивается, если вы сможете сказать, какое значение примет любая из этих переменных в разные периоды времени. Короче, верный признак того, что к вам попал дерьмокод — глобальные переменные.
То есть приношу я заказчику код скрипта ночами писанный, трудный, с применением всяких фичек — а он мне такой — «Ну ка ща проверим твой код!». Нажимает Ctrl+F, вводит global. Находит его в куске кода —
function uploaddata($filepath)
{
global $path, $filesettings;
Всё? Я попался? Теперь заказчик не примет мою работу, аргументируя тем, что на авторитетном ресурсе Хабр бравый защитник наших
Утрирую конечно…
Если бы я был разработчиком, то не принял бы. Или пришлось бы очень долго расказывать почему ты в функции используешь глобальные переменные…
А я пытаюсь «исправить» языковые особенности, например реализовать конструктор для php4 и желательно, что бы код потом работал в php5, без существенных переделок (ну в последнее время наоборот). И да! мой базовый класс называется Object.
Надо будет назвать его по другому, а то попадаю в базу сигнатур «дерьмокода» :).
Надо будет назвать его по другому, а то попадаю в базу сигнатур «дерьмокода» :).
/me пошёл тихонечко переименовывать каталог core в system…
К большому сожалению статья как минимум бесполезна, как максимум вредна. Этим страдают многие переводные материалы. Потому что когда автор переводит статью с Английского Языка по IT тематике почему-то автоматически считается, что материал чем-то ценен.
Грустная тенденция состоит в том, что авторы не задумываются о том, кому и зачем может принести пользу этот материал.
Если ты фрилансер, то главная оценка твоей работы — деньги, которые ты зарабатываешь. Если фрилансер при этом пишет «быдлокод» (по мне так это слово на полном серьезе могут говорить только идиоты), то это всего лишь значит, что он в начале пути и через год-два начнет делать нормальный код, а если не начнет то это проблемы его и его заказчиков.
С наемными кодерами немного другая ситуация. Его плохой код — проблема исключительно его начальства. Но опять же обоснованием плохого качества кода может быть только аргументированное объяснение — почему поддержка этого кода стоит дороже чем могла бы стоить, если бы код был другим.
Если не приводить аргументы почему это плохо для компании и для клиента, все претензии по «быдлокоду» остаются речами ээээ просто дурака.
И можно еще много чего по этому поводу написать. А резюме такое — люди, задумайтесь кому и зачем нужен ваш материал! Не засоряйте информационное пространство бессмыслицей!
Грустная тенденция состоит в том, что авторы не задумываются о том, кому и зачем может принести пользу этот материал.
Если ты фрилансер, то главная оценка твоей работы — деньги, которые ты зарабатываешь. Если фрилансер при этом пишет «быдлокод» (по мне так это слово на полном серьезе могут говорить только идиоты), то это всего лишь значит, что он в начале пути и через год-два начнет делать нормальный код, а если не начнет то это проблемы его и его заказчиков.
С наемными кодерами немного другая ситуация. Его плохой код — проблема исключительно его начальства. Но опять же обоснованием плохого качества кода может быть только аргументированное объяснение — почему поддержка этого кода стоит дороже чем могла бы стоить, если бы код был другим.
Если не приводить аргументы почему это плохо для компании и для клиента, все претензии по «быдлокоду» остаются речами ээээ просто дурака.
И можно еще много чего по этому поводу написать. А резюме такое — люди, задумайтесь кому и зачем нужен ваш материал! Не засоряйте информационное пространство бессмыслицей!
А что, наличие статических публичных функций в изначально статическом классе уже плохо? ИМХО, уж очень категорично сказано
По поводу 7 как раз согласен. На эту тему есть даже такое понятие — антипаттерн. Я так понимаю автор имеет в виду именно такую ситуацию.
Но ни в коем случае не является признаком плохого кода 6 и 9. 10 — тоже слишком категорично.
Но ни в коем случае не является признаком плохого кода 6 и 9. 10 — тоже слишком категорично.
3й «паттерн» обычно называют «спагетти код»
Sign up to leave a comment.
10 признаков php-приложения «с душком»