Допустимо ли оборачивать функции библиотеки PHP исключительно для изменения имен? - PullRequest
3 голосов
/ 02 апреля 2010

Этим летом я собираюсь запустить довольно большое PHP-приложение, в котором я буду единственным разработчиком (поэтому у меня нет никаких соглашений о кодировании, которые могли бы соответствовать моим).

PHP 5.3 - достойный язык IMO, несмотря на глупый маркер пространства имен.Но одна вещь, которая меня всегда беспокоила, это стандартная библиотека и отсутствие соглашения об именах.

Поэтому мне любопытно, было бы серьезно плохой практикой заключать в оболочку некоторые из наиболее распространенных функций стандартной библиотекив моих собственных функциях / классах, чтобы сделать имена немного лучше?Я полагаю, что это может также добавить или изменить некоторые функции в некоторых случаях, хотя на данный момент у меня нет примеров (я думаю, я найду способы сделать их OO или заставить их работать немного иначе, пока я работаю).

Если бы вы видели, как PHP-разработчик делал это, вы бы подумали: «Чувак, это один дурацкий разработчик?»

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

Ответы [ 4 ]

6 голосов
/ 02 апреля 2010

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

Я работал с кодом, в котором автор обернул вызовы таким образом, и это действительно вредит способности быстро понять код

Если бы вы видели, как PHP-разработчик делал это, вы бы подумали: «Чувак, это один дурацкий разработчик?»

Ну, нет ... но я бы подумал: "Черт ... Я должен выучить у этих ребят новый стандарт именования, который, хотя и из лучших побуждений, отнимет у меня время"

4 голосов
/ 02 апреля 2010

Полагаю, вы имеете в виду не только соглашения об именах, но и веселую смесь function (needle, haystack) и function(haystack, needle) порядков параметров.

Я могу полностью понять желание построить разумные обертки вокруг них в целях самообороны. Я все же предпочел бы этого не делать, просто потому, что он добавляет проприетарный слой в ваш проект, который усложнит понимание для других. Все знают, что делает array_push, но MyArrayFunctions::push может потребоваться посмотреть или даже посмотреть, чтобы выяснить, что он делает.

Я склонен придерживаться стандартов, хотя в этом случае они, по общему признанию, дрянные. Кроме того, с приличной IDE, которая может искать функции и параметры при вводе, проблема уже значительно уменьшена.

С другой стороны, я не вижу никакого вреда, скажем, в статическом классе Array, который приводит все push(), pop(), array_this() и array_that() в одну стандартную форму. Я бы сказал, что все зависит от вас.

2 голосов
/ 02 апреля 2010

Простые обертки не повлияют на вашу производительность, но это может сбить с толку любых будущих разработчиков проекта. Как программист PHP, вы постепенно начинаете ожидать странные соглашения об именах.

Если вы добавляете какие-либо функции, замечательно иметь согласованные соглашения. Я работал со статическим классом PHP, который обернул нативные функции массива (и добавил новые). Было довольно удобно всегда размещать одинаковые аргументы.

0 голосов
/ 05 июля 2010

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

Если вам действительно нужно это сделать, убедитесь, что вы прокомментировали его с помощью phpdoc, чтобы люди могли видеть правильный синтаксис в автозаполнении своей IDE.

...