Стандарты кодирования
Стандарты кодирования в SKY. во многом соотвествуют подобным стандартам, которые описаны для большинства известных фреймворк. Например смотрите zend. Ньюансы стандартов кодирования в SKY. в следующем: нужно понимать что в SKY., следуя принципу "как можно проще", не интерполируемые строки должны заключаться только в одинарные кавычки, но не в двойные, так как одинарные кавычки занимают меньше пикселей на экране монитора. Интерполируемые строки, содержащие внутри себя, переменные PHP должны заключаться в двойные кавычки. SQL запросы должны всегда заключаться в двойные кавычки, ввиду того, что даже если они не имеют интерполяционных переменных внутри себя, велика вероятность, что такие переменные могут быть добавлены в эти строки в течении развития проекта. Между тем чаще запросы SQL как раз содержат такие переменные внутри строки запроса и следуя принципу унификации, SQL запросы следует заключать в двойные кавычки всегда.
Для крышевания следует использовать инструкцию "die", а для нормального завершения скрипта инструкцию-синоним "exit".
Отличия от Zend
Отступы в SKY. делаются табуляцией. К сожалению в стандартах Zend неверно выбраны условности для некоторых вещей при кодировании. Табуляция в вашем редакторе текста, всегда должна быть настроена на расстояние в 4 пробела. Во первых, размер файлов будет меньше (вместо одного байта табуляции четыре пробела добавляют каждый раз 4 байта в Zend стандарте). Во вторых, при редактировании файлов (для изменения отступов), при копировании вертикальных блоков, в случае отступов на основе табуляции, чтобы выделить блок, необходимо нажать на клавиатуре одну кнопку, а в случае если отступы пробелы - 4 раза. Таким образом, экономится время программиста в SKY. И в третьих, при комментировании блока, когда отступы сделаны табуляцией, позиция строки справа от отступа сохраняется, а в случае пробелов - сдвигается, это выглядит менее красиво, либо нужно делать дополнительное удаление символов пробелов. Эти факторы имеют бОльший приоритет важности, чем тот фактор, что если отступы - пробелы, то в независимости от размера табуляции (настройки в редакторе), код (отступы) будут выглядеть "как пологается".
Во VIEW-файлах, рекомендуется открывающий PHP тег делать коротким, например, <?=$y_title?>
, это экономит время программиста, уменьшает размер файлов. Этот фактор более приоритетен, чем отсутствие необходимости, настроить работу php с поддержкой коротких тегов: short_open_tag = On
в файле php.ini.
Идентификаторы в SKY.
Идентификаторы в SKY. рекомендуется именовать также как и в большинстве известных сред программирования. Идентификаторы должны быть самоописывающиеся, т.е. имя идентификатора необходимо выбирать так чтобы он "говорил сам за себя". В коде первого и второго крыла считается нормальным делать сокращения терминов в именах идентификаторов, ввиду того что этот код наиболее часто используется и сокращения в аббревиатурах рано или поздно (для нового программиста) станет привычным. Нельзя делать сокращения, когда получаются двусмысленные аббревиатуры, например переменная $cli_sex - программист внес идентификатор, как имя метода класса или переменной, подразумевающий "пол клиента", между тем сокращения "CLI" ассоциируется с "Command line interface" - интерфейс командной строки. Так именовать идентификаторы нельзя.
В SKY. не используется верблюжья, как и венгерская нотация имен. Для разделения слов в именах, можно использовать символ подчеркивания. Идентификаторы и другие имена, в основном пишутся малыми буквами. Глобальные переменные и константы, которые предназначены для использования (могут быть затребованы) в любой части кода - пишутся заглавными буквами (за исключением переменных, которые имеют однобуквенный префикс), например $PROFILES. Однако (несмотря на положение переменной в глобальной области видимости), если логически переменная не подразумевает передачу своего значения в отдаленные части кода, а используется лишь в локальной части скрипта, в ее идентификаторе используются прописные буквы, например $i.
Итераторы рекомендуется именовать одной буквой, например $i, $j, $k. В SKY. используется система однобуквенных префиксов, например $p_name. Читайте об этом в статье Ядро SKY.
Еще некоторые ньюансы кодирования в SKY.
В операторах `if`, `while` и подобных ставится пробел, перед открывающей и закрывающей скобкой:
if ($flag) {
}
В функциях, после имени функции, пробел не ставится (и в описании и при вызове):
$magic = get_magic_quotes_gpc();
Стиль описания функций и классов, смотрите на примере кода wing.php.
Для комментария начинающего с символа # требуется один символ, а для аналогичного // два, поэтому в PHP коде, для комментария который должен остаться в финальном релизе скрипта не следует использовать //, нужно использовать # или /* .... */. Комментарий // можно использовать как временный, "для себя" с тем условием, что после некоторого времени, этот комментарий будет удален и не будет присутствовать в финальном коде.
Один файл PHP кода не должен превышать 600 строк, в самом крайнем случае 800 строк. Необходимо стремиться чтобы каждый файл PHP кода содержал минимальное кол-во строк, но нижний предел не меньше 100 строк (из соображений того что файлы должны быть максимально функциональны и выделение отдельго файла представляло некий функционал). Имеется ввиду, что необходимо стремиться сжимать код по строкам с той целью, чтобы в открытом редакторе было показано максимально много кода. Однако лаконичность кода также важна и в SKY. следует оставлять пустые строки между логически не сопряженными участками кода.
Стремиться записать пхп код в одну строку, для одного алгоритмического действия, но длина строки не должна превышать 150-160 символов.
Идея создания алгоритма для анализа качества кода
Такой алгоритм, может основываться на понятиях:
- Код X - код, качество, которого оценивается
- Энтропия native-интерфейса - это относительное понятие, например, в качестве native-интерфейса, для доступа к БД MySQL, можно рассматривать PHP модуль PDO::MySQL или C/C++ библиотеку для доступа к БД MySQL. Либо в качестве native-интерфейса для создания веб-приложений, можно рассматривать ядро SKY., либо framework ZEND, либо "голый язык PHP", либо один кремниевый транзистор. Энтропия native-интерфейса подразумевает кол-во информации, которой разработчик должен владеть для достижения идеальной реализации цели, которую позволяет сделать рассматриваемый интерфейс.
- Энтропия интерфейса надстройки (кода X) - в веб-программировании, повторно-используемый код, чаще представляется, как надстройка над кодом native-интерфейса, т.е. код можно рассматривать как новый объект, который решает проблемы native-интерфейса. Код создает новый интерфейс, который систематизирует native до необходимого уровня. При этом, энтропию интерфейса надстройки, следует рассматривать, как процент передачи гибкости упраления native-интерфейса.
- Величина кода обертки - абсолютное значение величины кода X, который не вносит никаких алгоритмов. Пример относительного значения:
function sql($query) { return mysql_query($query); }
- это 100% обертка, причем энтропия интерфейса надстройки в примере менее 100%, так как упущена возможность передавать второй параметр в функциюmysql_query
(это при условии, что нет более возможности использовать эту функцию напрямую). - Величина кода алгоритмизации - это абсолютное значение величины кода X, которая вносит новые алгоритмы в новый интерфейс
- Коэффициент кода обертки и алгоритмизации - в сумме составляют 100%. Это относительные понятие, которые показывают, сколько в коде X новых полезных алгоритмов и сколько малополезного оберточного кода, процентное содержание.
- 2do: другие понятия
Используя вышеприведенные понятия и развивая область рассмотрения, которая упоминается, можно построить алгоритм машинной оценки качества кода. Простейший алгоритм, вероятно не состоятельный, но указывающий путь: посчитать кол-во байт кода в PHP файлах, которые включаются при открытии определенной страницы на сайте. При этом циклы и ветвления (и код внутри их) считать как алгоритмический, а остальной код как оберточный. Программы ценны алгоритмами, поэтому высокий процент оберточного кода, будет свидетельствовать о низком качестве кода X.
Об использовании ООП в SKY. приложениях
Однажды, после появления новой отрасли - программирования, был сделан скачек, важный шаг, человечество переступило новый порог - был разработан объектно-ориентированный стиль программирования, ООП. Новинка оказалась настолько "вкусной", что до сих пор, многие программисты для того чтобы убить муху, готовы использовать ядерную бомбу! Этот абзац, частично является продолженнием мысли из предыдущего абзаца: ООП при малом количестве алгоритмического кода внутри методов классов, всегда вносит высокий уровень кода обертки! Это всегда делает код менее производительным, чем он мог бы быть, иногда делает интерфейс кода X более сложным чем native-интерфейс, который необходимо изучить прежде чем использовать! Конечно это плохо.
Перечислим случаи, когда необходимо использовать ООП:
- объект, который разрабатывается, имеет яркую объектную подоплеку, часто или всегда будет использоваться параллельно более одного экземпляра объекта
- когда важно не упустить высокий уровень энтропии native-интерфейса и при этом он достаточно сложен (объемен)
- если желательна инкапсуляция данных, при этом считается, что ядро (наиболее часто употребимая часть кода) стремиться быть выполнено не в стиле ООП
- объектный стиль реализует уникальную полезную идею. Пример - реализация паттерна MVC (идея формализации местоположения кода приложения).
Ядро SKY. для построения веб-приложений, выполнено не в стиле ООП! Это значительно упрощает процесс создания веб-приложений, их сопровождения, делает приложения более производительными... а также вносит другие положительные характеристики, по сравнению с framework, которые в основной, ядерной части приложений, подразумевают использование ООП. Энтропия интерфейса надстройки в SKY. снижена, по сравнению с native-интерфейсом, в код ядра SKY. включены только наиболее часто употребимые случаи использования кода, причем их уровень определяется, в основном, на основании парадигмы сложности SKY. - код ядра должен быть очень прост. Частные редкие случаи, не включены в код ядра, но использование их в SKY. доступно кардинально иным способом, нежели сохранение кодом ядра высокой энтропии native-интерфейса (высокой способности к конфигурированию).
Критика ZEND Framework
В настоящее время существует множество framework и CMS цель которых, упростить, ускорить создание и улучшить качество создаваемых веб-приложений, по сравнению с тем случаем, как если бы эти приложения были созданы без использования надстроек, на основе только native-интерфейса. Один из наиболее известных и популярных таких надстроек, есть ZEND Framework.
Итак, в случае ZEND (как и во многих других Framework), создается впечатление, что первоначальная цель "сделать надстройку полезной для програмирования (а для чего еще его делали?)" была оставлена без внимания и главной целью стало, создать библиотеку полезную для программистов полностью в ООП. Ошибка ZEND в словах - "полностью в ООП" - это полный бред, да простят меня почитатели ZEND, разве слова "полностью в ООП" имеют основания, разве использование ООП всегда оправдано? Ведь цель ZEND Framework - реальное практическое использование в жизни, а не выполненние дипломной работы по программированию в стиле ООП. Можно написать так:
class calculate2x2 {
function result() {
echo 2 * 2;
}
}
$object = new calculate2x2();
$object->result();
Не кажется ли вам, что написанное выше это бред и можно решить задачу проще?
Кроме того (в сравнении с SKY.) делать надстройку проносящюю через себя 100% энтропии native-интерфейса также бессмысленно. Пример: использование ZEND - форм, особо не вносит никакой пользы и не оказывает помощь программистам. Сложность использования форм в native-интерфейсе не особо отличается, но в случае ZEND - форм, нужно сначала изучить довольно сложный новый интерфейс, зачем это нужно? Делали, делали и... "поменяли шило на мыло"?
Конечно, использование надстроек как ZEND Framework оправдано, это лучше чем ничего, чем использование native-интерфейса, "голого PHP". Заметим, справедливо сказано, что "каша надстроек" варится давно, но нельзя с уверенностью сказать, что отрасль веб-программирования переступила новый порог.
Пороги развития программного обеспечения, Software
По причинам описанным в первой статье на этом сайте, следующие пороги, будем рассматривать в области веб-программирования.
- Первым порогом следует считать отрытие электричества и появление наук, предметом рассмотрения которых является ПО. Я думаю не у кого не возникнет сомнений, что электричество еще длительное время в будущем будет востребовано человечеством, в том числе как основа для исполнения алгоритмов и вообще ПО. Появятся новые основы для выполнения программ и будут развиваться те которые сейчас мало используются - оптические и другие, но, человечество живущее на Земле, никогда (или еще очень долго) не откажется вовсе от электричества, на том основании, что заменит его чем-то иным конкурентным и более совершенным. Поэтому, этот порог будем считать первым, фундаментальным
- Следующие несколько порогов в одном списке: изобретение транзисторов, изобретение цифровых интегральных схем, изобретение процессоров и микроконтроллеров (включая языки программирования ими - Ассемблеры), язык программирования C, изобретение объектно-ориентированного стиля программирования и языка C++. Заметим здесь, что много языков появившихся во время появления языка C (или чуть позже), просуществовав некоторое время исчезло, так как они являлись бредом.
- Отдельно выделим появление сетей, Интернет и протоколов обмена информацией
- Паттерны программирования - абстрактные алгоритмические шаблоны общего назначения, выделим также как отдельный порог развития ПО
- Следующий порог - появление скриптовых языков высокого уровня Perl, PHP и других. Совершенно очевидно, что многие из них являются конкурентными и много из них исчезнет (или уже исчезло), как Алгол, Фортран, Бейсик и др. (на предыдущих порогах развития), те, которые являются бредом (см. термины).
- Следующий порог - попытка создания надстроек для языков высокого уровня - framework и CMS с целью использовать повторно код, для более быстрого и качественного создания нового ПО - не является слишком значимым!
- Создание системы SKY. - централизованной глобальной системы развития идеального кода для повторного использования, а также решающей другие задачи для облегчения процесса создания ПО
- Неизвестные пороги - могут появиться в будущем
- Финальный порог достаточно ясен - создание идеального искусственного интеллекта, который заменит труд программистов. Человечество практически всегда развивает созданные им инструменты до уровня, когда прикладываются минимальные усилия и при этом извлекается максимальная польза. В случае ПО, это речевое (или мысленное) объяснение системе искусственного интеллекта, что нужно сделать, без явного программирования. Такая система будет подобна очень умному, опытному во всех областях программирования и чрезвычайно быстрому программисту, которая будет создавать идеальный код в режиме реального времени. Вероятно такая система будет развита из систем распознавания образов, которые уже сейчас широко используются
Обратите внимание: надстройки для языков высокого уровня - framework и CMS существуют уже достаточно давно. Многие из надстроек уже "умерли", либо были переписаны с чистого листа, даже их авторы иногда признают их несовершенство. Такие надстройки являются базисом для современных веб-программистов в их работе, и конечно облегчают труд. Тем не менее, отрасль веб-программирования остается чрезвычайно трудоемкой и интеллектуальноемкой. Скрипты практически всегда содержат большое количество багов и бесполезного кода, который никогда не используется, как и малоэффективный, бредовый код, который работает, но "вхолостую" неэффективно использует аппаратные ресурсы.
Большинство таких современных framework и CMS, является бредом с позции SKY., они решают некоторые задачи, но в комплексе, присущие им абстрактно поставленные цели, не достигают.
Система SKY. это новый порог в области развития ПО, которая заменит традиционные framework. Система SKY. это совершенно иной, новый путь предоставления кода для повторного использования, которая будет лишена недостатков описанных выше.