From 2a8300e03d9f6ef62f4e2f91f0a8c1d2c848709b Mon Sep 17 00:00:00 2001 From: Marcus Boerger Date: Wed, 21 Jan 2004 20:18:09 +0000 Subject: [PATCH] All technical reasons that prevented us from studlyCaps are solved and all current extensions as well as the whole PEAR framework follow this rule. So for consistency i readd it. # Also we had the discussion onece and decided for this. # Lookup the archieves --- CODING_STANDARDS | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/CODING_STANDARDS b/CODING_STANDARDS index 9feb43b851..bf9854b7cd 100644 --- a/CODING_STANDARDS +++ b/CODING_STANDARDS @@ -133,7 +133,22 @@ Naming Conventions [5] Variable names should be in lowercase. Use underscores to separate between words. -[6] Classes should be given descriptive names. Avoid using abbreviations +[6] Method names follow the 'studlyCaps' (also referred to as 'bumpy case' + or 'camel caps') naming convention, with care taken to minimize the + letter count. The initial letter of the name is lowercase, and each + letter that starts a new 'word' is capitalized. + + Good: + 'connect()' + 'getData()' + 'buildSomeWidget()' + + Bad: + 'get_Data()' + 'buildsomewidget' + 'getI()' + +[7] Classes should be given descriptive names. Avoid using abbreviations where possible. Each word in the class name should start with a capital letter, with words underscore delimited. The class name should be prefixed with the name of the 'parent set'. -- 2.50.1