To organize the development of Phenotype we like all developers to agree to some policies or maybe better called guidelines for the code itself and the svn usage.

Please see this as a draft for the moment, discussion follows in the forum!

Comments are useful. Just write down on content level what you´ve changed, in short words. Please don´t copy your code or semi-code in here. The people who read this are into Phenotype, but not deep into that code you worked with the last hours.

1. Good example

  fixed bug in installer regarding mod_rewrite (bug #134)

1. Bad example

  added else clause in function test123

There will be 3 main branches in the repository.

• trunk contains the main development line with the latest changes.
• tags contains copies of the complete branch of the system in a specific state. Tags will be at least created for every release, but there might be other important states that will be tagged. But there go only complete copies of the system, no single files. In this main branch will no development take place.
• branches contains copies of the system that are developed without contact to the main development line. This might be to test a new feature, but also to fix bugs in older releases. In this case, a branch is created as a copy either from the trunk or from an existing release (from tags).

For all main branches there are some rules:

• What you commit shall not damage anything else. This means, you have at least checked if your code is free of parser errors.
• If you work on an update of a function or an area, you should only commit your work if
  • it´s finished, means the code is written and you made some tests
  • you need some feedback and are sure that you don´t damage anything with your commit (the old stuff is also available for compatibility)
  • you made an announcement of what you will do and the core team
• If you create completely new functionality or work on bigger (long-term) changes, it may be useful to commit code that´s not finished. In this case please assure, that at least there are no parser errors that force php to exit or other fatal stuff.
• Branches and tags are created by the release manager or by everybody after clearing with the release manager.

The trunk branch is intended for all the changes that belong to the next official release. You should only commit work there that was assigned to you respectively that is on the plan for the next release to prevent completely uncontrolled growth.

Ocassionally the system will be released to the public. The time for this event is feature-driven, so we don´t intend to release a new version every X weeks or something like that.

Releases are named after the following schema:

• release_RNo_State

RNo is the relase number, something like 2.5.1. From that, 2.5 is the major release number. The rest will be just counted up. The State indicates to the public the intended audience and which target we aim with the release. This might be stable or something different (what we didn´t use yet). The release number during the development cycle is always the next major release number with the extension -current. Example: 2.6-current.

This means, an official release name example is release_2.5.1_stable.

We should define the naming of other tags here too when we need it.

I recommend using tabs all the time for the simple reasons that it is much easier to align everything using them, and tabs require less space in a file than multiple spaces. Also, if you set your editor to display a tab character as 8 spaces, but another developer prefers to have them represented as 4 spaces.

The three major operating systems (Unix, Windows and Mac OS) use different ways to represent the end of a line. Unix systems use the newline character (\n), Mac systems use a carriage return (\r), and Windows systems are terribly wasteful in that they use a carriage return followed by a line feed (\r\n).

I use simple newlines all the time, because the Windows way just doubles the size of your line breaks and the Mac OS way is technically incorrect in that a carriage return should only return you to the beginning of the line, ala the old typewriter systems.

If you develop on Windows (and many people do), either set up your editor to save files in Unix format or run a utility that converts between the two file formats.

All code files should be saved in ISO-8859-15. Exceptions might be some special files like templates or XML Files that require UTF-8 encoding. These files should show their encoding in the content header of the file.

Of the three major brace placement strategies two are acceptable, with the first one listed being preferable:

• Place brace under and inline with keywords:

         if ($condition)       while ($condition)
         {                     {
            ...                   ...
         }                     }

• Traditional Unix policy of placing the initial brace on the same line as the keyword and the trailing brace inline on its own line with the keyword:

         if ($condition) {     while ($condition) {
            ...                   ...
         }                     }

But please keep your choice consistent inside at least on function level. If you find code using not your preferred brace style change it only if you really reengineer most of the code, then change the complete function. It should be avoided to change this flip-flop style whenever another developer comes to the code, so please do this only if it´s really necessary.

For all the rest stuff, while crossreading I found an external coding standard that sounded not bad for me, maybe whe should adopt that one.