head	1.33;
access;
symbols
	HORDE_2_0_RC3:1.32.2.1
	HORDE_2_0:1.32.2.1
	HORDE_2_0_RC2:1.32
	RELENG_2:1.32.0.2
	HORDE_2_0_0_RC1:1.32
	HORDE_1_3_4:1.29
	HORDE_1_3_3:1.23;
locks; strict;
comment	@# @;


1.33
date	2001.11.19.17.26.36;	author chuck;	state Exp;
branches;
next	1.32;

1.32
date	2001.08.21.00.08.54;	author chuck;	state Exp;
branches
	1.32.2.1;
next	1.31;

1.31
date	2001.08.21.00.06.31;	author chuck;	state Exp;
branches;
next	1.30;

1.30
date	2001.08.09.16.04.58;	author chuck;	state Exp;
branches;
next	1.29;

1.29
date	2001.05.09.22.22.51;	author max;	state Exp;
branches;
next	1.28;

1.28
date	2001.04.04.21.38.19;	author max;	state Exp;
branches;
next	1.27;

1.27
date	2001.03.15.21.12.59;	author bjn;	state Exp;
branches;
next	1.26;

1.26
date	2001.02.26.07.31.12;	author max;	state Exp;
branches;
next	1.25;

1.25
date	2001.02.19.11.36.52;	author bjn;	state Exp;
branches;
next	1.24;

1.24
date	2001.01.10.23.05.53;	author avsm;	state Exp;
branches;
next	1.23;

1.23
date	2001.01.03.18.54.12;	author max;	state Exp;
branches;
next	1.22;

1.22
date	2001.01.02.20.30.34;	author chuck;	state Exp;
branches;
next	1.21;

1.21
date	2001.01.02.04.40.26;	author max;	state Exp;
branches;
next	1.20;

1.20
date	2000.12.23.04.48.28;	author chuck;	state Exp;
branches;
next	1.19;

1.19
date	2000.12.21.05.41.40;	author chuck;	state Exp;
branches;
next	1.18;

1.18
date	2000.09.19.17.45.23;	author bjn;	state Exp;
branches;
next	1.17;

1.17
date	2000.08.28.00.57.37;	author avsm;	state Exp;
branches;
next	1.16;

1.16
date	2000.08.16.16.45.32;	author jon;	state Exp;
branches;
next	1.15;

1.15
date	2000.08.11.22.45.45;	author chuck;	state Exp;
branches;
next	1.14;

1.14
date	2000.08.08.01.32.12;	author jon;	state Exp;
branches;
next	1.13;

1.13
date	2000.08.08.01.27.59;	author jon;	state Exp;
branches;
next	1.12;

1.12
date	2000.07.31.12.54.37;	author bjn;	state Exp;
branches;
next	1.11;

1.11
date	2000.06.30.19.11.55;	author jon;	state Exp;
branches;
next	1.10;

1.10
date	2000.06.30.05.28.23;	author jon;	state Exp;
branches;
next	1.9;

1.9
date	2000.06.28.02.30.31;	author bjn;	state Exp;
branches;
next	1.8;

1.8
date	2000.06.26.19.03.04;	author jon;	state Exp;
branches;
next	1.7;

1.7
date	2000.06.26.12.26.13;	author avsm;	state Exp;
branches;
next	1.6;

1.6
date	2000.06.03.16.32.34;	author chuck;	state Exp;
branches;
next	1.5;

1.5
date	2000.05.28.13.46.43;	author jon;	state Exp;
branches;
next	1.4;

1.4
date	2000.03.17.19.12.46;	author chuck;	state Exp;
branches;
next	1.3;

1.3
date	2000.03.17.02.17.51;	author chuck;	state Exp;
branches;
next	1.2;

1.2
date	2000.03.16.23.34.29;	author jon;	state Exp;
branches;
next	1.1;

1.1
date	2000.03.16.21.24.15;	author chuck;	state Exp;
branches;
next	;

1.32.2.1
date	2001.11.20.04.59.58;	author chuck;	state Exp;
branches;
next	;


desc
@@


1.33
log
@try and explain how to name libraries
@
text
@===========================================================================
|| Horde Coding Standards                                                ||
===========================================================================

$Horde: horde/docs/CODING_STANDARDS,v 1.32 2001/08/21 00:08:54 chuck Exp $

-------------
[1] Indenting
=============

Use an indent of 4 spaces, with no tabs.


----------------------
[2] Control Structures
======================

These include if, for, while, switch, etc. Here is an example if statement,
since it is the most complicated of them:

  if ((condition1) || (condition2)) {
      action1;
  } elseif ((condition3) && (condition4)) {
      action2;
  } else {
      defaultaction;
  }

Control statements should have one space between the control keyword
and opening parenthesis, to distinguish them from function calls.

In the case of an if with no else clauses, and only a 1 line action,
the curly braces may be omitted:

  if (condition) action;

or:

  if (condition)
      action;

Whichever is more readable under the circumstances is preferred.

For switch statements:

  switch (condition) {
  case 1:
      action1;
      break;

  case 2:
      action2;
      break;

  default:
      defaultaction;
      break;

  } // switch


------------------
[3] Function Calls
==================

Functions should be called with no spaces between the function name,
the opening parenthesis, and the first parameter; spaces between commas
and each parameter, and no space between the last parameter, the
closing parenthesis, and the semicolon. Here's an example:

  $var = foo($bar, $baz, $quux);

As displayed above, there should be one space on either side of an
equals sign used to assign the return value of a function to a
variable. In the case of a block of related assignments, more space
may be inserted to promote readability:

  $short         = foo($bar);
  $long_variable = foo($baz);


------------------------
[4] Function Definitions
========================

Function declaractions follow the "one true brace" convention:

  function fooFunction($arg1, $arg2 = '')
  {
      if (condition) {
          statement;
      }
      return $val;
  }

Arguments with default values go at the end of the argument list. Always
attempt to return a meaningful value from a function if one is appropriate.


--------------------
[5] Naming Libraries
====================

Libraries (any file located in the 'lib/' directory of the application)
should be named with capital letters at the beginning of each word. Use
studlycaps for naming; a session cache class would be stored in
lib/SessionCache.php.

If the library/class is extended, the extending files should be stored in a
directory under 'lib/' with the same name as the original library.
Subclasses follow the exact same naming requirements, except that if the
subclass is instantiated by a factory method, it should be all lowercase.

Example:
The "Example Library" library should be saved as "lib/ExampleLibrary.php".
Any file extending the library/class should be stored in the directory
  "lib/ExampleLibrary/".


------------
[6] Comments
============

Inline documentation for classes should follow the Javadoc convention.  An
overview of the Javadoc standard can be found here:

    http://java.sun.com/products/jdk/javadoc/writingdoccomments/index.html


------------------
[7] Including Code
==================

If you are including a class, function library, or anything else which would
cause a parse error if included twice, always use include_once. This will
ensure that no matter how many factory methods we use or how much dynamic
inclusion we do, the library will only be included once.

If you are including a static filename, such as a conf file or a template
that is _always_ used, use require.

If you are dynamically including a filename, or want the code to only be
used conditionally (an optional template), use include.


-----------------
[8] PHP Code Tags
=================

Always use <?php ?> to delimit PHP code, not the <? ?> shorthand.
This is required for PEAR compliance and is also the most portable way
to include PHP code on differing operating systems and setups.

However, when embedding echo commands, you should use the shorthand
notation: <?= $name ?> instead of <?php echo $name ?>
This improves the clarity of HTML templates that are scattered with
these constructs.

-------------------------
[9] Header Comment Blocks
=========================

All source code files in the Horde distribution should contain the following
comment block as the header:

Example for LGPL'ed Horde code:

/*
 * $Horde: horde/docs/CODING_STANDARDS,v 1.32 2001/08/21 00:08:54 chuck Exp $
 *
 * Copyright 1999, 2000, 2001 Original Author <author@@example.com>
 * Copyright 2001 Your Name <you@@example.com>
 *
 * See the enclosed file COPYING for license information (LGPL).  If you 
 * did not receive this file, see http://www.fsf.org/copyleft/lgpl.html.
 */

Example for GPL'ed application code:

/*
 * $Horde: horde/docs/CODING_STANDARDS,v 1.32 2001/08/21 00:08:54 chuck Exp $
 *
 * Copyright 1999, 2000, 2001 Original Author <author@@example.com>
 * Copyright 2001 Your Name <you@@example.com>
 *
 * See the enclosed file COPYING for license information (GPL).  If you 
 * did not receive this file, see http://www.fsf.org/copyleft/gpl.html.
 */

There's no hard rule to determine when a new code contributer should be
added to the list of authors for a given source file.  In general, their
changes should fall into the "substantial" category (meaning somewhere
around 10% to 20% of code changes).  Exceptions could be made for rewriting
functions or contributing new logic.

Simple code reorganization or bug fixes would not justify the addition of a
new individual to the list of authors.


-------------
[10] CVS Tags
=============

Include the <dollar>Horde<dollar> CVS vendor tag in each file.  As each
file is edited, add this tag if it's not yet present (or replace existing
forms such as <dollar>Id<dollar>, "Last Modified:", etc.).


-----------------
[11] Example URLs
=================

Use "example.com" for all example URLs, per RFC 2606.


---------------------
[12] php.ini settings
=====================

All Horde code should work with register_globals = Off. This means using
$HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_COOKIE_VARS, $HTTP_SESSION_VARS,
$HTTP_SERVER_VARS, and $HTTP_ENV_VARS to access all get, post, cookie,
session, server, and environment data, respectively.

All Horde code should work with error_reporting = E_ALL. Failure to do so would
result in ugly output, error logs getting filled with lots of warning messages,
or even downright broken scripts.

All Horde code should work regardless of the setting of magic_quotes_gpc.
Form data should be passed through Horde::dispelMagicQuotes(), which will
run stripslashes on it if necessary.

No Horde code should assume that '.' is in the include path. Always
specify './' in front of a filename when you are including a file in
the same directory.


-------------------------
[13] XHTML 1.0 Compliancy
=========================

All tag names and parameters must be lower case including javascript
event handlers:

    <font color="#FFFFFF">...</font>
    <a href="http://example.com" onmouseover="status=''" onmouseout="status=''">...</a>

All tag parameters must be of a valid parameter="value" form (numeric
values must also be surrounded by quotes).  For parameters that had no
value in HTML, the parameter name is the value.  For example:

    <input type="checkbox" checked="checked">
    <select name="example">
        <option selected="selected" value="1">Example</option>
    </select>
    <td nowrap="nowrap">Example</td>

All tags must be properly closed.  Tags where closing is forbidden must end
with a space and a slash:

    <br />
    <hr />
    <img src="example.gif" alt="Example" />
    <input type="submit" value="Example" />

All form definitions must be on their own line and either fully defined within
a <td></td> pair or be outside table tags. Forms must also aways have an action
parameter:

    <form method="post" action="http://example.com/example.cgi">
    <table>
        <tr><td>example</td></tr>
    </table>
    </from>

    <table>
        <tr><td>
            <form action="javascript:void(0)" onsubmit="return false;">
            </form>
        </td></tr>
    </table>

All JavaScript tags must have a valid language and type parameters:

    <script language="JavaScript" type="text/javascript">
    <!--
    ...
    // -->
    </script>

Nothing may appear after </html>, therefore include any common footers after
all other output.

All images must have an alt parameter:

    <img src="example.gif" alt="<?= _("Example") ?>" />
    <?= Horde::img("example.gif", 'alt="' . _("Example") . '"') ?>

Input field of type "image" does not allow the border parameter, and may render
with a border on some browsers.  Use the following instead:

   <a href="" onclick="document.formname.submit(); return false;"><?= Horde::img("example.gif", 'alt="' . _("Example") . '"' ?></a>


--------------------------------
[14] Database Naming Conventions
================================

All database tables used by Horde resources and Horde applications
need to make sure that their table and field names work in all
databases. Many databases reserve words like 'uid', 'user', etc. for
internal use, and forbid words that are SQL keywords (select, where,
etc.).

A good way to do this for field names is to make the field name
tableName_fieldName.

Other general guidelines: Table names should be singular (Users);
field names should be singular (user_Name).
@


1.32
log
@add another db note
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.31 2001/08/21 00:06:31 chuck Exp $
d96 1
a96 1
Arguments with default values go at the end of the argument list.  Always
d100 20
d121 1
a121 1
[5] Comments
d131 1
a131 1
[6] Including Code
d147 1
a147 1
[7] PHP Code Tags
d160 1
a160 1
[8] Header Comment Blocks
d169 1
a169 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.31 2001/08/21 00:06:31 chuck Exp $
d181 1
a181 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.31 2001/08/21 00:06:31 chuck Exp $
d200 3
a202 3
------------
[9] CVS Tags
============
d210 1
a210 1
[10] Example URLs
d217 1
a217 1
[11] php.ini settings
d239 1
a239 1
[12] XHTML 1.0 Compliancy
d306 1
a306 1
[13] Database Naming Conventions
@


1.32.2.1
log
@MFH: keep CODING_STANDARDS up to date
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.33 2001/11/19 17:26:36 chuck Exp $
d96 1
a96 1
Arguments with default values go at the end of the argument list. Always
a99 20
--------------------
[5] Naming Libraries
====================

Libraries (any file located in the 'lib/' directory of the application)
should be named with capital letters at the beginning of each word. Use
studlycaps for naming; a session cache class would be stored in
lib/SessionCache.php.

If the library/class is extended, the extending files should be stored in a
directory under 'lib/' with the same name as the original library.
Subclasses follow the exact same naming requirements, except that if the
subclass is instantiated by a factory method, it should be all lowercase.

Example:
The "Example Library" library should be saved as "lib/ExampleLibrary.php".
Any file extending the library/class should be stored in the directory
  "lib/ExampleLibrary/".


d101 1
a101 1
[6] Comments
d111 1
a111 1
[7] Including Code
d127 1
a127 1
[8] PHP Code Tags
d140 1
a140 1
[9] Header Comment Blocks
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.33 2001/11/19 17:26:36 chuck Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.33 2001/11/19 17:26:36 chuck Exp $
d180 3
a182 3
-------------
[10] CVS Tags
=============
d190 1
a190 1
[11] Example URLs
d197 1
a197 1
[12] php.ini settings
d219 1
a219 1
[13] XHTML 1.0 Compliancy
d286 1
a286 1
[14] Database Naming Conventions
@


1.31
log
@add databases section
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.30 2001/08/09 16:04:58 chuck Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.30 2001/08/09 16:04:58 chuck Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.30 2001/08/09 16:04:58 chuck Exp $
d297 3
@


1.30
log
@note about E_ALL

Submitted by: Cynic <cynic@@mail.cz>
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.29 2001/05/09 22:22:51 max Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.29 2001/05/09 22:22:51 max Exp $
d158 1
a158 1
Example for GPL'ed module code:
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.29 2001/05/09 22:22:51 max Exp $
d217 1
d283 14
@


1.29
log
@- move all href="javascript:..." to href="" onclick="...; return false;"
  this should fix the IE+frames+ssl+nt4 problems where IE would drop
  encryption because it thinks that javascript: is a none-secure URL.

- update CODING_STANDARDS accordingly

- onClick -> onclick as per CODING_STANDARDS in menu.php
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.28 2001/04/04 21:38:19 max Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.28 2001/04/04 21:38:19 max Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.28 2001/04/04 21:38:19 max Exp $
d204 4
@


1.28
log
@fixing couple of typos
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.27 2001/03/15 21:12:59 bjn Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.27 2001/03/15 21:12:59 bjn Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.27 2001/03/15 21:12:59 bjn Exp $
d253 1
a253 1
            <form action="javascript:void(0)" onsubmit="return false">
d258 1
a258 1
All javascript tags must have a valid language and type parameters:
d277 1
a277 1
   <a href="javascript:document.formname.submit()"><?= Horde::img("example.gif", 'alt="' . _("Example") . '"' ?></a>
@


1.27
log
@Typo.
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.26 2001/02/26 07:31:12 max Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.26 2001/02/26 07:31:12 max Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.26 2001/02/26 07:31:12 max Exp $
d228 1
a228 1
    <select name="examble">
d245 1
a245 1
    <form method="POST" action="http://example.com/example.cgi">
@


1.26
log
@fix an example and a typo in section 12
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.25 2001/02/19 11:36:52 bjn Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.25 2001/02/19 11:36:52 bjn Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.25 2001/02/19 11:36:52 bjn Exp $
d229 1
a229 1
        <option selected="selected" value="1">Exampe</option>
@


1.25
log
@Typo.
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.24 2001/01/10 23:05:53 avsm Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.24 2001/01/10 23:05:53 avsm Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.24 2001/01/10 23:05:53 avsm Exp $
d238 1
a238 1
    <img src="example.gif" />
d277 1
a277 1
   <a href="javascript:document.formname.submit()"><= Horde::img("example.gif", 'alt="' . _("Example") . '"' ?></a>
@


1.24
log
@Add 2001 to example license headers
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.23 2001/01/03 18:54:12 max Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.23 2001/01/03 18:54:12 max Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.23 2001/01/03 18:54:12 max Exp $
d223 1
a223 1
All tag parameters must be of a valid parameter="value" form (numaric
@


1.23
log
@Unless I missed something (which is likely) Horde and IMP should both
be fully XHTML 1.0 compliant now.  The only exception is that, according
to validator, there is no "wrap" parameter for textarea elements and I
couldn't find a way to get around it with css.

The other issue is that form elements inside <td></td> produce an
unsightly blank space.  I was able to get around it in message.php and
filters.php by using only one form outside the table (which is cleaner
anyway), but mailbox.php uses different methods for different forms
making such an endevour a little more difficult.  Any ideas?

Also added a more sections to the CODING_STANDARDS doc and fixed a few
minor problems that escape my memory at the moment.
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.22 2001/01/02 20:30:34 chuck Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.22 2001/01/02 20:30:34 chuck Exp $
d151 2
a152 2
 * Copyright 1999, 2000 Original Author <author@@example.com>
 * Copyright 2000 Your Name <you@@example.com>
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.22 2001/01/02 20:30:34 chuck Exp $
d163 2
a164 2
 * Copyright 1999, 2000 Original Author <author@@example.com>
 * Copyright 2000 Your Name <you@@example.com>
@


1.22
log
@more xhtml fixes. validator.w3.org was telling me that selected="true",
checked="true", etc were invalid; the correct form is apparently
selected="selected", nowrap="nowrap", etc. I've revised section 12 of
CODING_STANDARDS accordingly.
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.21 2001/01/02 04:40:26 max Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.21 2001/01/02 04:40:26 max Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.21 2001/01/02 04:40:26 max Exp $
d223 3
a225 3
All tag parameters must be of a valid parameter="value" form. For
parameters that had no value in html, the parameter name is the
value. For example:
d229 1
a229 1
        <option selected="selected">Exampe</option>
d241 17
d260 16
a275 5
   <script language="JavaScript" type="text/javascript">
   <!--
   ...
   // --
   </script>
d277 1
@


1.21
log
@Happy New Year everyone!

-- xhtml 1.0 compliancy (not finished)
-- docs/CODING_STANDARDS section 12
-- tabs -> spaces where ever found

I ran into a few stumbling blocks with the validator.  It
seems that you can't put <form>...</form> tags inside tables
unless the form is complete within one <td></td> tag.  In fact,
once you open a <table> tag you can't put anything else unless
its within the <td></td> pair (or <th></th> of course). This
would make compliancy and layout rather difficult to achieve
so if anyone has any brilliant ideas, do tell.

Also I found out that php's url rewriter isn't compliant in
two respects.  The hidden input tag it adds is in ALL CAPS;
it is not terminated correctly: <input ...> instead of
<input ... />.  This along with "arg_seperator" being set to
'&' instead of '&amp;' would break compliancy.  I'm thinking
we should suggest disabling url_rewriter.tags php.ini setting
since we do our own session propogation.
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.20 2000/12/23 04:48:28 chuck Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.20 2000/12/23 04:48:28 chuck Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.20 2000/12/23 04:48:28 chuck Exp $
d224 2
a225 1
parameters that have no specific value, "true" can be assigned:
d227 1
a227 1
    <input type="checkbox" checked="true">
d229 1
a229 1
        <option selected="true">Exampe</option>
d231 1
a231 1
    <td nowrap="true">Example</td>
@


1.20
log
@add a note to CODING_STANDARDS about working without '.' in the include path.
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.19 2000/12/21 05:41:40 chuck Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.19 2000/12/21 05:41:40 chuck Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.19 2000/12/21 05:41:40 chuck Exp $
d212 36
@


1.19
log
@add a note about php.ini settings to our standards
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.18 2000/09/19 17:45:23 bjn Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.18 2000/09/19 17:45:23 bjn Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.18 2000/09/19 17:45:23 bjn Exp $
d208 4
@


1.18
log
@Typos:  parenthesis and parameter
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.17 2000/08/28 00:57:37 avsm Exp $
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.17 2000/08/28 00:57:37 avsm Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.17 2000/08/28 00:57:37 avsm Exp $
d194 14
@


1.17
log
@Make a note about using <?= instead of <?php echo in the 'tags'
section.  Couldn't find any documentation on it in the php manual
to place a reference to this feature though ...
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.16 2000/08/16 16:45:32 jon Exp $
d30 1
a30 1
and opening parenthese, to distinguish them from function calls.
d67 1
a67 1
the opening parenthese, and the first paramete; spaces between commas
d69 1
a69 1
closing parenthese, and the semicolon. Here's an example:
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.16 2000/08/16 16:45:32 jon Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.16 2000/08/16 16:45:32 jon Exp $
@


1.16
log
@Rewording part of the copyright notice.
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.15 2000/08/11 22:45:45 chuck Exp $
d134 4
d149 1
a149 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.15 2000/08/11 22:45:45 chuck Exp $
d161 1
a161 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.15 2000/08/11 22:45:45 chuck Exp $
@


1.15
log
@fix typo
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.14 2000/08/08 01:32:12 jon Exp $
d142 1
a142 1
For LGPL'ed Horde code:
d145 1
a145 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.14 2000/08/08 01:32:12 jon Exp $
d150 2
a151 2
 * See the enclosed file COPYING for license information (LGPL).  If you did
 * not received such a file, see also http://www.fsf.org/copyleft/lgpl.html.
d154 1
a154 1
For GPL'ed module code:
d157 1
a157 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.14 2000/08/08 01:32:12 jon Exp $
d162 2
a163 2
 * See the enclosed file COPYING for license information (GPL). If you did
 * not receive such a file, see also http://www.fsf.org/copyleft/gpl.html.
@


1.14
log
@Silly typo fix: LPGL -> LGPL
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.13 2000/08/08 01:27:59 jon Exp $
d145 1
a145 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.13 2000/08/08 01:27:59 jon Exp $
d157 1
a157 1
 * $Horde: horde/docs/CODING_STANDARDS,v 1.13 2000/08/08 01:27:59 jon Exp $
d162 2
a163 2
 * See the enclosed file COPYING for license information (GPL).  If you did
 * not received such a file, see also http://www.fsf.org/copyleft/gpl.html.
@


1.13
log
@Add new entry concerning header comment blocks and copyright
information.
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.12 2000/07/31 12:54:37 bjn Exp $
d145 1
a145 1
 * $Horde$
d150 1
a150 1
 * See the enclosed file COPYING for license information (LPGL).  If you did
d157 1
a157 1
 * $Horde$
@


1.12
log
@Use example.com for example URLs.  This is more doc. standards than coding,
but I'll put it here so it doesn't get lost... feel free to move it if you
think a new file is justified.
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.11 2000/06/30 19:11:55 jon Exp $
d135 41
d177 1
a177 1
[8] CVS Tags
d185 3
a187 3
----------------
[9] Example URLs
================
@


1.11
log
@s/function declarations/function definitions
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.10 2000/06/30 05:28:23 jon Exp $
d142 7
@


1.10
log
@Adding a section on "function declarations" and re-ordering the items
a bit.
@
text
@d5 1
a5 1
$Horde: horde/docs/CODING_STANDARDS,v 1.9 2000/06/28 02:30:31 bjn Exp $
d82 3
a84 3
-------------------------
[4] Function Declarations
=========================
@


1.9
log
@The primary purpose was to add item 7, use of <dollar>Horde<dollar>, but
as long as I was in there... :-)  Correct me if I'm wrong about the space
after if, but of course I'm not wrong.  ;-)
@
text
@d1 3
a3 3
=================================================================
|| Horde Coding Standards                                      ||
=================================================================
d5 7
a11 1
$Horde$
d15 1
a15 1
[1] Control Structures
d63 1
a63 1
[2] Function Calls
d82 13
a94 3
-------------
[3] Indenting
=============
d96 2
a97 1
Use an indent of 4 spaces, with no tabs.
d101 1
a101 1
[4] Comments
d111 1
a111 1
[5] Including Code
d127 1
a127 1
[6] PHP Code Tags
d136 1
a136 1
[7] CVS Tags
@


1.8
log
@A little wording nit.
@
text
@a2 1
|| $Id: CODING_STANDARDS,v 1.7 2000/06/26 12:26:13 avsm Exp $    ||
d5 3
d23 3
d27 1
a27 1
the curly braces may be ommitted:
d118 7
@


1.7
log
@Added a note about using <?php tags and not <?
@
text
@d3 1
a3 1
|| $Id: CODING_STANDARDS,v 1.6 2000/06/03 16:32:34 chuck Exp $   ||
d108 2
a109 2
Always use <?php ?> to delimit PHP code, and not the <? ?> shorthand.
This is required for PEAR compliance, and is also the most portable way
@


1.6
log
@adding a note on include_once, require, and include to CODING_STANDARDS.
@
text
@d3 1
a3 1
|| $Id: CODING_STANDARDS,v 1.5 2000/05/28 13:46:43 jon Exp $   ||
d50 1
d102 11
@


1.5
log
@Adding a note about Javadoc comments with a pointer to:

    http://java.sun.com/products/jdk/javadoc/writingdoccomments/index.html
@
text
@d3 1
a3 1
|| $Id: CODING_STANDARDS,v 1.4 2000/03/17 19:12:46 chuck Exp $   ||
d85 16
@


1.4
log
@trying to get things to line up prettily. okay, so i'm petty sometimes. :)
@
text
@d3 1
a3 1
|| $Id: CODING_STANDARDS,v 1.3 2000/03/17 02:17:51 chuck Exp $ ||
d75 10
@


1.3
log
@very minor: add switch to the list of control structures. :)
@
text
@d1 4
a4 4
===============================================================
|| Horde Coding Standards                                    ||
|| $Id: CODING_STANDARDS,v 1.2 2000/03/16 23:34:29 jon Exp $ ||
===============================================================
@


1.2
log
@Removed the alternate style for if-else statements and added a section for
switch() statements.
@
text
@d3 1
a3 1
|| $Id: CODING_STANDARDS,v 1.1 2000/03/16 21:24:15 chuck Exp $ ||
d10 1
a10 1
These include if, for, while, etc. Here is an example if statement,
@


1.1
log
@first shot at coding standards. definitely missing a lot, but it's a start.
comments/additions/revisions welcome.
@
text
@d3 1
a3 1
|| $Id: CODING_STANDARDS,v 2.2 1999/11/04 19:20:07 jon Exp $ ||
a20 9
The following is also acceptable:

  if ((condition1) || (condition2)) {
      action1;
  }
  else {
      defaultaction;
  }

d33 16
@

