OpenNET: статья - Хороший и плохой PHP код. (php)

Ключевые слова: php, (найти похожие документы)
From: Scorpion <ss-suchkov@yandex.ru.> Newsgroups: email Date: Mon, 18 Dec 2007 14:31:37 +0000 (UTC) Subject: Хороший и плохой PHP код. Моё рабочее время делится как правило на три части(помимо завтрака и обеда): собственно сама работа, поиск нового и интересного; что помогает в работе; чтение bash.org.ru конечно(у всех свои слабости). Очень часто наталкиваюсь на статьи о хорошем и плохом коде. Причём нередко то, что считается плохим кодом в одной статье, признаётся хорошим в другой. Наибольшее противостояние идёт вокруг "отделения дизайна от кода". Одни говорят о том, что совмещать код нельзя, ибо все "нормальные языки программирования" этого не допускают, другие говорят что отделение это лишь прихоть дизайнеров, которые не хотят разбираться в коде(хотя. почему они должны, собственно?). Вопрос конечно спорен, но я придерживаюсь точки зрения о том, что код и дизайн должны быть разделены на сколько это возможно. Об этом я уже говорил в одной из моих прошлых статей, но сейчас речь не об этом, вернее это только частность. Во время поиска чего-то новенького я наткнулся на занимательную статью, которая мне очень понравилась, и которую я бы хотел вам привести. Поскольку она на английском языке, далее следует её перевод. Хороший и Плохой PHP код автор: Кевин Янг Источник: http://www.sitepoint.com/blogs/2007/05/25/good-and-bad-php-code/ На собеседовании с кандидатом на должность PHP-кодера в SitePoint я всегда задаю свой любимый вопрос(так как ответ на него даёт понять на сколько хорош программист): "Какая разница, на ваш взгляд, между хорошим и плохим PHP кодом?" Я люблю этот вопрос за то что он даёт возможность проверить не только знание функций, но и многие другие стороны знаний в отношении PHP. А для проверки знания функций в PHP существуют специальные тесты: Zend's PHP certification например. Ответ на этот вопрос позволяет понять, например, работал ли разработчик с чужим, плохо написаным кодом, оставшимся от плохого программиста-предшественника, и возникали ли у него трудности при этом. Ну и конечно становится понятно, будет ли "доработка" такой же кривой, или обретёт человеческое лицо. В действительности, я не знаю точного ответа на собственный вопрос, но я точно знаю определённые вещи, которые хочу услышать. Я вот и они: Хороший PHP код должен быть структурированым. Длинные куски кода должны быть разбиты на функции или методы, которые позволяют выполнять отдельные операции и описаны "простым" кодом. Функции и методы в свою очередь должны быть снабжены понятными коментариями, позволяющими понять суть выполняемых операций. На сколько это возможно, код должен быть отделён от конечного представления, которым является HTML/CSS/JavaScript код. ООП даёт очень мощные инструменты для написания вашего кода структурированым и разбитым на мелкие, просты элементы. Хороший код должен быть последовательным. Это значит что вы должны следовать определённым правилам именования переменных и функций, стараясь стандартизировать код таким образом, чтобы он был понятен любому разработчику. Хороший код должен быть портируемым. В PHP есть ряд функций, таких как "magic quotes" например, использование которых может привести к сбоям в работе кода, в зависимости от того используются они или нет. Конечно, если вы знаете что делаете, можете писать код для конкретной платформы. Хороший код должен быть безопасным. Несмотря на то, что после установки php отлично работает, многие аспекты работы интерпритатора находятся в руках разработчика. Это прежде всего безопасность. На сегодняшний день существует масса потенциальных опасностей: XSS-уязвимости, CSRF-уязвимости, инъекции кода и т.д. После того, как кандидат ответил на вопрос, чаще всего я уже знаю будет он у нас работать или нет. Конечно, есть и такие программисты, которые просто не могут внятно сформулировать те тезисы, которые я привёл. Для них мы придумали специальный экзамен. Многие вопросы кажутся поверхностными и простыми, как будто ответы лежат на поверхности. Однако, они дают кандидатам возможность показать на сколько они педантичны(на сколько они внимательны к деталям). Следующий "плохой" код - очень упрощёный пример кода, элюстрирующий то что мы хотели бы узнать на экзамене. Сам вопрос мог бы звучать примерно так: "Каким образом нужно переписать этот код, чтобы он стал правильным и что называется хорошим?" <? echo("Search results for query: " . $_GET['query'] . "."); ?> Основная проблема данного скрипта в том, что он выводит переданое значение напрямую, там самым создаёт XSS-уязвимость. Хотя есть и другие нарекания. Итак, что бы мы хотели услышать/увидеть в качестве ответа? <? echo("Search results for query: " . htmlspecialchars($_GET['query']) . "."); ?> Именно этого мы и ждали. Мы предупредили XSS-уязвимость использовав функцию htmlspecialchars которая превращает "опасные символы" в их "безопасный" аналог. При этом код можно ещё улучшить: <?php if (isset($_GET['query'])){ echo 'Search results for query: ', htmlspecialchars($_GET['query'], ENT_QUOTES), '.'; } ?> Теперь код выглядит так, как у разработчика, которого мы бы хотели нанять: "Короткий" вариант PHP тега (<?) заменён на его "длинного" прородителя, который более универсален(и дружелюбен стандарту XML). Перед тем, как вывести значение $_GET['query'], проверяется существует ли переменная. Для этого используется функция isset. Круглые скобочки вокруг значения, выводимого через echo убраны за ненадобностью. Строковые переменные заключены в апострофы, вместо кавычек, для того, чтобы переменные можно было вставлять без усилий в строку. Вместо конкатенатора(.), который посылает на вывод единую строковую переменную, элементы передаваемые оператору echo разделены запятыми для небольшого выигрыша в производительности. Задание дополнительного параметра ENT_QUOTES позволяют безоговорочно применять замену к апострофу. К сожалению, из ищущих работу программистов, не так много тех кто смог бы ответить на мой вопрос правильно. По крайней мере здесь, в Мельбурне. Мы потратили три месяца пока нашли того, кто отвечал бы всем нашим требованиям! Итак, как вы ответите на мой вопрос? какие ещё факторы позволяют отличить хороший код от плохого? Что вы ищите в соискателях, когда ищете PHP разработчика? Частичная или полная публикация перевода допускается лишь с согласия автора перевода и с его предварительного согласия. ICQ: 107876417 Перевод статьи опубликован: http://scorpion.amateria.ru/2007/12/17/xoroshij-i-ploxoj-php-kod-good-and-bad-php-code.html

2.10, max, 15:25, 20/12/2007 [^] [ответить] [смотреть все] [показать ветку]	+/–
Именно С namespaces похоже таки опять получится как всегда, ну да ладно, если в... весь текст скрыт [показать] [показать ветку]

3.11, Diman, 15:35, 20/12/2007 [^] [ответить] [смотреть все]	+/–
Каждый должен заниматься своим делом. Нормальный руководитель должен знать кому делегировать задачу тестирования программиста, дизайнера или бухгалтера, а не корчить из себя профессионала. Кесарю кесарево, как грится. По поводу любви. Это как с женщинами - чем больше на нее потратишь (времени/денег/etc), тем больше "любишь". А если еще и дети общие, то ваще пипец. Так и тут, если есть большие наработки в определенной области, просто глупо от них отказываться только потому, что в основе лежит кривой процедурный API.

3.12, Diman, 15:57, 20/12/2007 [^] [ответить] [смотреть все]	+/–
>в то, что когда-нибудь появится нормальный gc, я лично вообще не >верю, хотя не хватает его катастрофически. PS. По поводу GC не стоит отчаиваться заранее. Процесс идет http://aspn.activestate.com/ASPN/Mail/Message/php-dev/3588702

2.14, Diman, 18:21, 21/12/2007 [^] [ответить] [смотреть все] [показать ветку]

+/–

>Как такового различия не вижу, все-равно сказать плохая инструкция процессора, код есть
>код. По существу - тот который не работает.

Написать код, понятный компьютеру, может любой. Написать код, который поймет человек гораздо труднее (c) К.Бек

По моему более точного определения хорошего/плохого кода не найти.

3.15, crl, 17:56, 29/12/2007 [^] [ответить] [смотреть все]	+/–
Хороший программист - тот, кто действительно любит программирование. Технические асекты придут со временем и практикой, а любовь к программированию - она либо есть, либо - нет.

4.17, admax, 00:19, 22/01/2008 [^] [ответить] [смотреть все]	+/–
+1. Абсолютно согласен. С любовью к программированию приходит и опыт, и умения