Стандарты кодирования

Стандарты кодирования в 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 символов.

Идея создания алгоритма для анализа качества кода

Такой алгоритм, может основываться на понятиях:

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

Об использовании ООП в SKY. приложениях

Однажды, после появления новой отрасли - программирования, был сделан скачек, важный шаг, человечество переступило новый порог - был разработан объектно-ориентированный стиль программирования, ООП. Новинка оказалась настолько "вкусной", что до сих пор, многие программисты для того чтобы убить муху, готовы использовать ядерную бомбу! Этот абзац, частично является продолженнием мысли из предыдущего абзаца: ООП при малом количестве алгоритмического кода внутри методов классов, всегда вносит высокий уровень кода обертки! Это всегда делает код менее производительным, чем он мог бы быть, иногда делает интерфейс кода X более сложным чем native-интерфейс, который необходимо изучить прежде чем использовать! Конечно это плохо.

Перечислим случаи, когда необходимо использовать ООП:

Ядро 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

По причинам описанным в первой статье на этом сайте, следующие пороги, будем рассматривать в области веб-программирования.

Обратите внимание: надстройки для языков высокого уровня - framework и CMS существуют уже достаточно давно. Многие из надстроек уже "умерли", либо были переписаны с чистого листа, даже их авторы иногда признают их несовершенство. Такие надстройки являются базисом для современных веб-программистов в их работе, и конечно облегчают труд. Тем не менее, отрасль веб-программирования остается чрезвычайно трудоемкой и интеллектуальноемкой. Скрипты практически всегда содержат большое количество багов и бесполезного кода, который никогда не используется, как и малоэффективный, бредовый код, который работает, но "вхолостую" неэффективно использует аппаратные ресурсы.

Большинство таких современных framework и CMS, является бредом с позции SKY., они решают некоторые задачи, но в комплексе, присущие им абстрактно поставленные цели, не достигают.

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

комментировать