Культура программирования

#php

Хотелось бы узнать о культуре программирования в php. много интересует например нужно
ли проверять например функции которые находяться в другом файле или проверять сами
файлы есть ли они вообще и т.д. где можно об этом почитать?    

Ответы

Ответ 1

Обновляемый набор лучших практик:

http://www.phptherightway.com/

Перевод на русский (на момент написания этого поста отставал от оригинала на английском
на год):

http://getjump.me/ru-php-the-right-way/


Ответ 2

Стандарты PSR. Обеспечат вашему коду читаемость и портируемость.
Принципы SOLID (wiki).
Классика: DRY, KISS (хабр + YAGNI).
Что я хотел бы добавить конкретно про PHP:

PHP, местамии, довольно ненадежный язык. Всегда используйте строгое сравнение (===,
!==), кроме тех случаев, когда абсолютно точно необходимо нестрогое (==, !=).
Покрывайте все, что возможно тестами: это действительно просто и экономит уйму времени
на поиск ошибки.
Если нет четкого ТЗ по какому-то компоненту, то пишите сразу с прицелом на расширение,
делайте как минимум заготовки для тех методов, которые могут понадобиться.
Всегда, всегда, всегда комментируйте код и обновляйте комментарии при малейшем чихе.
Как только проект разрастется, вы скажете спасибо самому себе и автоматическому ввыводу
этих комментариев в IDE.
Проверки. Делайте их везде, где считаете нужным. Помните, что если они и начнут тормозить
код, от них можно будет легко избавиться.
Проверки #2. Всегда проверяйте входные значения (input) на соответствие ожидаемому.
Если вас будут ломать, то в первую очередь будут ломать именно здесь.
Проверки #3. Если ваша проверка не прошла - обязательно выведите соответствующее
сообщение. Сэкономит миллиард нервов, когда какая-то из проверок вдруг упадет, а всего
их десять, и непонятно какая именно упала.
Логи. Если есть возможность их писать - пишите. Если напишите какую-то апишку - лог
останется единственным местом, где можно будет отловить неисправность.
Официальные доки по PHP не особо пестрят исключениями, но на самом деле это довольно
мощный инструмент. Вместо trigger_error всегда создавайте исключение. Исключения можно
наследовать; в PHP опять же это не очень часто встречается, но лично мне, например,
удобно иметь целую систему исключений, в которой я смогу понять ошибку уже по названию
класса исключения.
Не стесняйтесь пользоваться чужими разработками. Помните, что отдельно разбросанные
по вебу куски кода и классы обычно являются собственностью сайта govnokod.ru, а вот
библиотеки, которые реализуют богатый функционал, имеют столь же богатую версионную
историю и найдены на гитхабе, будут, скорее всего, очень полезны.
Не бойтесь писать классы, не ведитесь на призывы оптимизировать код, пока он не работает.
Обычно первая проблема научившегося писать новичка - это чрезмерная оптимизация там,
где она не нужна, боязнь писать класс из-за того, что он "долго грузится" и пр. Как
только в голову приходят мысли реализовать компонент функциями или называть переменные
покороче, чтобы побыстрее работало - гоните их прочь, помните, что самое главное в
коде - его читаемость и несвязность (см. следующий пункт). Если вы можете вернуться
к коду через три месяца, прочитать комментарии и понять, как он работает, то вы и оптимизировать
его сможете тогда же. Если вы написали оптимизированный код, который невозможно прочитать,
то вы его уже не сможете толком расширить.
Пишите слабо связанные компоненты. База данных должна заниматься только базой данных,
класс подключения по FTP не должен знать, запускается он на винде или на линуксе -
если такой вопрос встает, то надо написать базовый класс и отнаследовать от него линуксовый
и виндовый подклассы, чтобы загрузчик компонентов сам решил, какой ему нужен. Это позволит
легко "вынуть" класс и заменить его, не ломая все приложение и делая изменения только
в пределах одного класса (если например, внезапно сменится ОС на хостинге). (Вообще,
с FTP пример плохой, но, надеюсь, понятно, о чем я говорю).
Нет ничего страшного, чтобы набросать "примерный" код, который будет работать через
раз и кое-как, чтобы сделать какие-то примерки. Однако он должен быть немедленно переписан,
как только вы поняли, что вы от него хотите, потому что как только что-то начнет зависеть
от его публичного интерфейса - у вас начнется dependency hell, и куча времени может
быть потрачена впоследствии на переход на обновленный интерфейс.
У вас, как у программиста, есть ограниченный набор ресурсов: концетрация, количество
объектов в "оперативной памяти", усталость, свободное время. Ваша задача - писать такой
код, чтобы использовать их по-минимуму - для этого и нужны четкие стандарты написания
кода, минимальная связность и прочее - это позволяет направить ресурсы именно туда,
где они нужны, а не распылять их по всему проекту. Проект может расширяться бесконечно,
ваши физические возможности - нет.
Читайте. Лучше всего - мануалы к фреймворкам: увидите, как пишется код, как структурируется,
какие существуют методики, а главное, рядом будет написано что и почему происходит
в том или ином куске кода.
И самое последнее: в любом проекте внезапно может появиться разработчик или консультант.
Пишите код так, чтобы он мог его без проблем понять: ясно и четко.