Coding standards

Coding standards in SKY. in many aspects meet the similar standards described for the bigger part of famous frameworks. For example, let's look at zend. Peculiarities of coding standards in SKY. are the following: it is necessary to understand that in SKY., following the principle "as simple as possible", the lines which cannot be interpolated must be enclosed in single quotes, but not in double, as single quotation marks take less pixels on the screen. Interpolated lines containing PHP variables must be enclosed in double quotation marks. SQL queries must always be enclosed in double quotation marks, as even if they do not have the interpolated variables, there is a good chance that such variables can be added to these lines within the project development. Meanwhile SQL queries ost often contain these variables in the query lines and following the principle of unification, SQL queries should be enclosed in double quotation marks.

Differences from Zend

Spaces in SKY. are made with tabbing. Unfortunately in Zend standards settings for some things during encoding were selected incorrectly. Tabbing in your text editor must always be set to the interval of 4 spaces. First of all, the file size will be smaller (instead of a single byte of tabbing four spaces add each time 4 bytes in the Zend standard). Secondly, when you edit a file (to change indents), if you copy the vertical blocks, in the case of indentation based on tabbing, to select a block, you need to press one button on the keyboard, and if indentation is made with spaces - you need to press it 4 times. Thus, a programmer's time is saved with SKY. And thirdly, when commenting the block where indentation is made by tabbing, the position of the line to the right of the indentation is preserved, and in the case of spaces, it looks less beautiful, or you need to do additional removal of space characters. These factors are of more importance than the fact that if indentation is made with spaces, then regardless of the size of tabbing (settings in the editor), the code (indents) will look like "it must".

In VIEW files, it is recommended to make the opening PHP tag shorter, for example <?=$y_title?>, it saves the time of a programmer and reduces the size of files. This factor is of more priority than absence of need to configure php work with short tag enabled:short_open_tag = On in php.ini file.

Identifiers in SKY.

It is recommended to name identifiers in SKY. like in most of the known programming environments. Identifiers must be self-descriptive, i.e. you should choose the name for an identifier so that it would "speak for itself". In the code of the first and second wing it is considered to be normal to reduce the terms in the names of identifiers, because that code is most often used and acronyms in abbreviations sooner or later (for a new programmer) will become common. You must not make acronyms when you can get ambiguous abbreviations, for example a variable $cli_sex - a programmer introduced an identifier as the name for the class method or variable, implying "hald of a customer". Meanwhile an acronym "CLI" is associated with a "Command line interface". You must not name the identifiers like that.

SKY. does not use camel as well as Hungarian notation of names. To separate words in a name, you can use the underscore character. Identifiers and other names are mostly written in small letters. Global variables and constants, which are intended to be used (may be required) in any part of the code - are capitalized (except for the variables, which have a single-letter prefix), for example $PROFILES. However (despite the position of a variable in the global scope), if a variable logically does not imply a transfer of its value to distant parts of the code and is only used in the local part of the script, uppercase letters, such as $i, are used in its identifier.

It is recommended to name iterators with one letter, for example $i, $j, $k. In SKY. we use a system of single-letter prefixes, for example $p_name. You can read about it in the article Core SKY.

Some more peculiarities of encoding in SKY.

In the operators ' if ', ' while ' and the like you should put a space before the opening and closing parenthesis:

if ($flag) {


In functions, after the name of a function, do not put a space (both in the description and at call):

$magic = get_magic_quotes_gpc();

You can see the style of descriptions of functions and classes on the example of the code wing.php.

For the comment beginning with the # character you need one character, and for the similar // two, that is why in PHP code for the comment which must appear on the final release of the script you should not use //, you must use # or /* ... */. You can use the comment // as a temporary one, "for yourself" on the condition that, after some time, the comment will be deleted and will not be present in the final code.

One file of PHP code must not exceed 600 lines, in extreme case - 800 lines. You must try to make every PHP code file contain the minimum number of lines, but the lower limit must be not less than 100 lines (due to the fact that the files should be as functional as possible, and selection of a separate file would be a certain functionality). We mean that you must contract the code in terms of lines, so that in the open editor you could see as much of the code as possible. However, the minimalism of the code is also important and in SKY. you should leave blank lines between the code sections which are not logically related.

You should try to write PHP code in one line for one algorithmic tasks, but the length of the line should not exceed 150-160 characters.

The idea of creating an algorithm to analyze the quality of the code

Such an algorithm may be based on the concepts of:

Using the above given concepts and developing the mentioned scope of review, it is possible to build a machine assessment algorithm for the code evaluation. The simplest algorithm which is probably not consistent, but it is showing the way: to count the number of bytes of the code in PHP files which are initiated when you open a specific page on the site. At the same time, looping and branching (and the code inside them) should be considered as an algorithmic code, and the rest of the code - as a wrapping one. A software is valuable because of its algorithms, so a high percentage of a wrapper code will indicate a low quality of X code.

On the use of OOP in SKY. applications

One day, when a new industry - programming - appeared, it was a big leap, an important step when the mankind crossed a new threshold - an object-oriented programming was developed, OOP. The novelty was so "delicious" that till now many programmers in order to kill a fly are ready to use a nuclear bomb! This paragraph is partly a continuation of the idea of the previous paragraph: OOP with its little quantity of algorithmic code inside the class methods, will always introduce a high level of the wrapper code! It always makes the code less productive than it could be, sometimes it makes the interface of the X code more complex than the native-interface, which must be studied before its application! Of course it is bad.

Let us enumerate the cases when you need to use OOP:

SKY. core for building Web-applications is not in OOP! It greatly simplifies the process of creating a Web-application, their maintenance, makes an application faster ... as well as makes other positive characteristics, compared to the framework, which in the main, core part of applications assume the use of OOP. The add-in interface entropy in SKY. is reduced compared to the native-interface. SKY. core code includes only the most commonly used cases and their level is determined mainly on the basis of the paradigm of SKY. complexity - the core code must be very simple. Special rare cases are not included in the core code, but their use in SKY. is possible in completely different way, than through saving as a core code of high entropy of the native-interface (with high ability to configure).

Criticism of ZEND Framework

Currently, there are a lot of framework and CMS designed to simplify, speed up and improve the quality of your Web-applications, as compared to the case when these applications were created without the use of add-ins, based only on the native-interface. One of the most famous and popular of such add-ins is ZEND Framework.

So, in the case of ZEND (as in many other Framework), it seems that the original aim - to "make an add-on useful for programming (and what else could it be designed for?)" -was disregarded and the main objective was to create a library which would be useful for programmers in OOP. ZEND's mistake is in the words - "entirely in OOP". It is complete nonsense, I apologies to the fans of ZEND. Do the words "entirely in OOP" are qualified, is application of OOP always justified? After all, the purpose of ZEND Framework is an actual practical use in life, not writing a research paper on programming in OOP style. You could write this way:

class calculate2x2 {
    function result() {
         echo 2 * 2;
$object = new calculate2x2();

Don't you think that the above is nonsense and you can solve the task easier?

In addition (compared to SKY.) it is nonsense to make an add-in which takes a 100% entropy of the native-interface. Example: application of ZEND-forms does not add any positive features and does not give assistance to programmers. The complexity of using forms in the native-interface is not very different, but in the case of ZEND-form, you must first learn a fairly complex new interface, why do we need it? We have been putting so much effort into it and ... "bargained one trouble for another"?

Of course, the application of add-ins like ZEND Framework is justified, it is better than nothing, than application of the native-interface, "bare PHP". Let us point out that "all this add-ins mess" is quite an old story, but it is not possible to say safely that the Web-programming industry has crossed a new threshold.

Thresholds of the software development

For the reasons described in the first article on this site, we are going to consider the following thresholds in the field of Web-programming.

Please note down: add-ins for high level languages - framework and CMS have existed for quite a long time. Many of the add-ons have already "died", or have been rewritten from scratch, even their authors sometimes admit their imperfection. These add-ins are the basis for today's Web-developers in their work, and of course make it easier to work. However, the industry of Web-programming is extremely labour-intensive and knowledge-based. Scripts almost always contain a large number of bugs and useless code that is never used, as well as ineffective delusional code that works, but inefficiently uses hardware resources.

Most of these modern framework and CMS is nonsense from the point of view of SKY., they solve some problems, but in a complex, that do not reach the abstract goals inherent to them.

SKY. system is a new threshold in the software development, which will replace the traditional framework. SKY. system. is totally different, a new way of providing code for reuse, which will have no drawbacks described above.