Серьезно, я должен написать плохой код PHP? [закрытый]
Указатель NULL - это тот, который указывает на никуда. Когда вы разыскиваете указатель p, вы говорите «дайте мне данные в месте, хранящемся в« p ». Когда p является нулевым указателем, местоположение, хранящееся в p, является nowhere, вы говорите «Дайте мне данные в месте« нигде ». Очевидно, он не может этого сделать, поэтому он выбрасывает NULL pointer exception.
В общем, это потому, что что-то не было правильно инициализировано.
16 ответов
Я думаю, что Joomla и Wordpress не являются самыми большими примерами хороший код PHP без преступления. У меня нет ничего персонального против людей, работающих над ним, и замечательно, как они позволяют людям иметь веб-сайт/блог, и я знаю, что много людей проводит все их свободное время на любом из тех проектов, но качество кода довольно плохо (без преступления).
объявления безопасности Обзора за прошлый год, если Вы не верите мне; также принятие Вас ищет производительность от любого из этих двух, их код не выделяется там также. Таким образом, это ни в коем случае не хороший код, но Wordpress и Joomla и Excel на frontend - довольно простой в использовании, люди получают веб-сайт и могут сделать материал .
И вот почему они так успешны, люди не выбирают их на основе качества кода, но на том, что они позволили им сделать.
Для ответа на вопрос производительности, да, это верно, что весь хороший материал (функции, классы, и т.д.) замедляет приложение. Таким образом, я предполагаю, является ли Ваше приложение/сценарий всем в одном файле, пусть будет так. Не стесняйтесь писать плохой код PHP затем.
, Как только Вы расширяетесь и запускаетесь к дублирующему коду, необходимо рассмотреть компромисс (в скорости), который взяло с собой написание удобного в сопровождении кода. :-)
, по моему скромному мнению, этот компромисс является довольно маленьким из-за двух вещей:
- ЦП дешев.
- Разработчики не дешевы.
, Когда необходимо возвратиться в код через шесть месяцев с этого времени, думайте, сохранили ли те нано секунды выполнение его, все еще сложите, когда необходимо исправить противную ошибку (три или четыре раза из-за дублированного кода).
можно сделать все виды вещей сделать PHP выполненным быстрее. Обычно люди рекомендуют кэш, такой как APC. APC является действительно потрясающим. Это выполняет все виды оптимизации в фоновом режиме для Вас, например, кэширования байт-кода файла PHP и также предоставляет Вам функции в пространстве пользователя для сохранения данных.
Так, например, при парсинге конфигурационного файла каждый раз, когда Вы работаете, тот диск сценария i/o действительно очень важен. С простым apc_store () и apc_fetch () можно сохранить проанализированный конфигурационный файл или в основанном на файле или в основанном на памяти (RAM) кэш и получить его оттуда, пока кэш не истек или удален.
APC не является единственным кэшем, конечно.
Если вы посмотрите на php-код wordpress, он помечает php-теги между html, что приводит к спагетти в моем уме.
Phpbb3, однако, намного лучше в этом отношении. Например, он имеет строгое разделение между частью php и частью стилей, которые представляют собой файлы в формате xhtml с тегами {template}, анализируемыми механизмом шаблонов. Который намного чище.
Если Вы - то, который волновался о каждом бите на эффективности, то, с какой стати Вы используете язык сценариев? Необходимо программировать на намного более быстром языке (вставьте скомпилированный язык фаворита здесь), вероятно, приводя к больше, и меньше читаемого кода, но он будет работать действительно быстро, и можно все еще стремиться к лучшему кодированию методов.
Серьезно, если Вы кодируете для рабочей скорости, Вы не должны использовать PHP вообще.
При разработке веб-приложений с архитектурным шаблоном MVC можно значительно извлечь выгоду из кэширования и сериализации. Можно кэшировать представления или части его, и можно сериализировать модели.
На основе опыта, модели часто анализируют и генерируют большинство данных, это отображается. Если Вы знаете, что определенная модель не будет генерировать новые данные часто, как модель, которая анализирует канал RSS, можно было просто наполнить его где-нибудь со всеми проанализированными данными и обновлять его время от времени.
Основная сила PHP состоит в том, что это быстро и легко получить рабочее приложение. Та сила прибывает из возможности записать, что свободный (плохой) код и иметь ее все еще работает несколько ожидаемым способом.
, Если Вы имеете возможность, должен сохранить несколько циклов ЦП, PHP не то, что необходимо использовать. Когда веб-приложения PHP работают плохо, это происходит намного более вероятно из-за неэффективных запросов, не скорости выполнения кода.
Конечно, Вы не должны писать плохой код PHP. Но после того как у Вас есть что-то плохое записанное, можно всегда использовать представление в качестве оправдания :-)
Для ответа на первый вопрос да, это верно, и это также верно для скомпилированного кода операции. Да можно сделать код быстрее путем предотвращения вызовов функции кроме крайних случаев, где код становится слишком большим из-за дублирования кода.
необходимо сделать то, что Вы любите, "Мне нравится писать хорошо организованный, человекочитаемый код с методами везде, где блок кода был бы повторен".
, Если Ваша попытка совершить это ужасное злодеяние удаления всех вызовов функции, по крайней мере, использует профилировщика и только делает это к 10% Вашего кода, который имеет значение.
Это - преждевременная оптимизация. В то время как оператор верен, что вызов функции стоит больше, чем увеличение локальной целочисленной переменной (почти все стоит больше), затраты на вызов функции являются все еще очень низкими по сравнению с запросом базы данных.
См. также:
В 99% случаев необходимо лучше волноваться о понятности кода. Напишите код, легкий протестировать, понять и поддержать.
В тех немногих случаях, где производительность действительно является критическими, языками сценариев как PHP, не Ваш лучший выбор. Существует причина, которая много основных библиотечных функций в PHP записаны в C, в конце концов.
Особенно с быстрым интерпретатором как PHP's, я не думаю, что отсутствие удобочитаемости/пригодности для обслуживания КОГДА-ЛИБО стоит эффективности, Вы можете (или не может!) получают от него.
И примечание о WordPress: я сделал большой просмотр кода WordPress. Не предполагайте, что те люди знают что-либо о хорошем коде.
Лично, в то время как могут быть издержки для вызова функции, если это означает, что я пишу код, однажды (параметризованный), и затем использую его в 85 местах, я ПУТЬ далее вперед, потому что я могу зафиксировать его в одном месте.
Языки сценариев имеют тенденцию давать людям идею, которые "достаточно хороший" и "работы" единственные критерии для рассмотрения при кодировании.
Необходимо видеть ответы на этот вопрос: разработчик должен стремиться к удобочитаемости или производительности сначала?
Для суммирования согласия: Если Вы не знаете для факта (посредством тестирования/профилирования), что Ваша производительность должна быть обращена в некоторой определенной области, удобочитаемость намного более важна.
В каком количестве "эффективности" Вы нуждаетесь? Вы даже имели размеры? Преждевременная оптимизация является корнем всего зла, и оптимизация без измерения ВСЕГДА преждевременна.
Помнят также правила Клуба Оптимизации .
- первое правило Клуба Оптимизации, Вы не Оптимизируете.
- второе правило Клуба Оптимизации, Вы не Оптимизируете без измерения.
- , Если Ваше приложение работает быстрее, чем протокол базовой передачи, оптимизация закончена.
- Один фактор за один раз.
- Никакие маркетиры, никакие расписания маркетира.
- Тестирование продолжится, пока оно имеет к.
- , Если это - Ваша первая ночь в Клубе Оптимизации, необходимо записать тестовый сценарий.
Пример того, как микрооптимизация приводит к макро-замедлению:
, Если Вы серьезно рассматриваете вручную встраивающие функции, рассмотрите вручную разворачивающие циклы.
JMPs являются дорогими, и если можно устранить циклы путем разворачивания и также устранить все условные блоки, Вы устраните все то время, потраченное впустую, просто ища вокруг кэша ЦП.
Переменное увеличение во времени выполнения является медленным также, как вытаскивает вещи из базы данных, таким образом, необходимо встроить все эти данные в код также.
На самом деле, загружая интерпретатор для того, чтобы просто выполнить код и скопировать память пользователю исчерпывающе расточительно, почему мы только не предварительно вычисляем все возможные страницы и храним каждую страницу в памяти, готовой пойти так ее просто копия мадам? конечно, это быстро!
А-ч, теперь у нас есть та медленная вещь, названная Интернетом между нами, который препятствует пользовательскому опыту и ограничивает, сколько содержания мы можем использовать, как насчет мы предварительно вычисляем страницы заранее, и архивируем их всех и выполняем их на пользователях локальная машина? это будет действительно быстро!
, Но это пропадает зря циклы CPU, многие из них, что со временем загрузки страницы и содержимым браузера, представляющим и т.д., мы пропустим посредника и просто поставим страницы им на печатных медиа!. Genius!.
/ меня наблюдает, что Ваша компания выходит из строя на ее поверхности, в то время как Вы проводите 10 лет, предварительно вычисляя (вручную), и не печатая страницы никто не хочет видеть.
Это может звучать глупым Вам, но к остальной части нас, то, что Вы предложили, просто настолько смешно.
Оптимизация хороша, но разграничьте где-нибудь разумный, таким образом, Вы не должны волноваться о будущих людях, которые работа над кодом, разыскивающим Вас в Вашем сне для того, чтобы иметь такую дрянную кодовую базу, это неудобно в сопровождении.
примечание: да, я использую хинду. как Вы предполагали?
Напишите пару 10-минутных примеров и запустите их в своем профилировщике.
Это скажет вам, какой из них быстрее с точностью до миллисекунды.
Если вы этого не сделаете. у меня нет профилировщика, опубликуйте их здесь, и я запущу их в моем профилировщике PHPEd.
Я подозреваю, что большая часть разницы во времени, если таковая имеется, возникает из-за необходимости открывать файл, в котором хранится класс, но это тоже нужно будет протестировать.
Затем спросите себя, заботитесь ли вы так сильно о нескольких миллисекундах по сравнению с необходимостью поддерживать спагетти-код - заметит ли кто-нибудь из ваших пользователей?
Изменить
Профилировщик не будет имитировать большие объемы трафика, но он скажет вам, какой метод быстрее для одного пользователя и какие части кода используют сколько времени. Особенно, если вы профилируете повторяющиеся операции - скажем, по 1000 раз в цикле.
Те, кто будет читать вам лекции о микрооптимизации кода, обычно те же, которые будут иметь 50 SQL-запросов на страницу, что в сумме займет 2 секунды, потому что они никогда не слышали о профилировании. Но их код оптимизирован !!! (и чертовски медленно)
Факт: добавить еще один веб-сервер не сложно. Репликация базы данных есть. Оптимизация кода веб-сервера может привести к чистым потерям, если она увеличивает нагрузку на БД.
Примечание: 2-3 мс для простых страниц (например, темы форума), включая SQL, - хорошая цель для веб-сайта PHP. Раньше это делал мой старый сайт.