Changeset 6198 for trunk/documents
- Timestamp:
- 10/16/06 15:41:49 (2 years ago)
- Files:
-
- 1 modified
-
trunk/documents/articles/js_style_guide.rest (modified) (15 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/documents/articles/js_style_guide.rest
r3068 r6198 31 31 package lower never multiple words 32 32 class UpperLower 33 public method lowerUpper whether class or instance method. lower_case() is acceptable only if the particular function is mimic ing another API.33 public method lowerUpper whether class or instance method. lower_case() is acceptable only if the particular function is mimicking another API. 34 34 public var lowerUpper 35 35 constant UpperLower or UPPER_LOWER … … 75 75 obj.getSomeValue() 76 76 77 F. Public class variables MUST be written using upperLower case.78 G. Private class variables MAY be written using ``_ upperLower`` (with77 F. Public class variables MUST be written using lowerUpper case. 78 G. Private class variables MAY be written using ``_lowerUpper`` (with 79 79 preceding underscore):: 80 80 … … 85 85 } 86 86 87 H. Variables that are intended to be private, but cannot be based on the88 semantics of Javascript, SHOULD prepended with a "_" (underscore) char::89 90 this._somePrivateVariable = statement 91 92 N B Note that the above variable also follows the convention for a87 H. Variables that are intended to be private, but cannot be, based on the 88 semantics of Javascript, SHOULD be prepended with a "_" (underscore) char:: 89 90 this._somePrivateVariable = statement; 91 92 Note that the above variable also follows the convention for a 93 93 private variable. 94 94 95 95 I. Generic variables SHOULD have the same name as their type:: 96 96 97 setTopic(topic) // where topic is TypeOfTopic97 setTopic(topic) // where topic is of type Topic 98 98 99 99 J. All names SHOULD be written in English. 100 K. Variables with a large scope SHOULD have globally unambiguious names ,101 ambiguity MAY be distinguished by package mem ebership. Variables with100 K. Variables with a large scope SHOULD have globally unambiguious names; 101 ambiguity MAY be distinguished by package membership. Variables with 102 102 small or private scope MAY be more terse still. 103 103 L. The name of the return object is implicit, and SHOULD be avoided in a … … 129 129 MouseEventHandler 130 130 131 NBThe base class CAN be dropped from a name if it is obviously131 The base class CAN be dropped from a name if it is obviously 132 132 implicit in the name:: 133 133 134 134 MouseEventHandler as opposed to MouseUIEventHandler. 135 135 136 Specific Naming conventions136 Specific Naming Conventions 137 137 *************************** 138 138 139 139 A. The terms get/set SHOULD NOT used where a field is accessed, unless the 140 140 variable being accessed is lexically private. 141 B. "is" prefix SHOULD be used for boolean variables and methods142 NB. Alternatives include "has", "can" and "should"141 B. The "is" prefix SHOULD be used for boolean variables and methods. 142 Alternatives include "has", "can" and "should". 143 143 C. The term "compute" CAN be used in methods where something is computed. 144 144 D. The term "find" CAN be used in methods where something is looked up. … … 146 146 concept is established. 147 147 F. UI Control variables SHOULD be suffixed by the control type. 148 ex.leftComboBox, topScrollPane148 Examples: leftComboBox, topScrollPane 149 149 G. Plural form MUST be used to name collections. 150 H. "num" prefix or "count" postfix SHOULD be used for variables150 H. The "num" prefix or "count" postfix SHOULD be used for variables 151 151 representing a number of objects. 152 152 I. Iterator variables SHOULD be called "i", "j", "k", etc. 153 J. Compl iment names MUST be used for compliment entities.154 ex.get/set, add/remove, create/destroy, start/stop, insert/delete,153 J. Complement names MUST be used for complement entities. 154 Examples: get/set, add/remove, create/destroy, start/stop, insert/delete, 155 155 begin/end, etc. 156 156 K. Abbreviations in names SHOULD be avoided. … … 169 169 B. Tabs (set to 4 spaces) SHOULD be used for indentation. 170 170 C. If your editor supports "file tags", please append the appropriate tag 171 at the end of the file enable others to effortlessly obey the correct171 at the end of the file to enable others to effortlessly obey the correct 172 172 indentation guidelines for that file:: 173 173 174 174 // vim:ts=4:noet:tw=0: 175 175 176 C. The incompleteness of split line MUST be made obvious::176 C. The incompleteness of a split line MUST be made obvious:: 177 177 178 178 var someExpression = Expression1 179 179 + Expression2 180 + Expression3 180 + Expression3; 181 181 182 182 var o = someObject.get( … … 206 206 E. Loops / iterative declarations 207 207 208 1. Only loop control statements MUST be included in the "for ()"208 1. Only loop control statements MUST be included in the "for" loop 209 209 construction. 210 210 2. Loop variables SHOULD be initialized immediately before the loop; 211 211 loop variables in a "for" statement MAY be initialized in the "for" 212 212 loop construction. 213 3. The use of "do...while" loops are acceptable (unlike in Java)214 4. The use of "break" and "continue" is not discouraged (unlike in Java) 213 3. The use of "do...while" loops is acceptable (unlike in Java). 214 4. The use of "break" and "continue" is not discouraged (unlike in Java). 215 215 216 216 F. Conditionals … … 235 235 236 236 A. Block statements. 237 237 238 1. Block layout SHOULD BE as illustrated below:: 238 239 … … 242 243 } 243 244 244 2. If statementsSHOULD have the following form::245 2. An "if" statement SHOULD have the following form:: 245 246 246 247 if(someCondition){ … … 252 253 } 253 254 254 3. for statementsSHOULD have the following form::255 3. A "for" statement SHOULD have the following form:: 255 256 256 257 for(initialization; condition; update){ … … 258 259 } 259 260 260 .. FIXME: (alex) this reference should use reST reference syntax! 261 262 4. while statement SHOULD follow the form in example VI.A.1. 263 5. a do...while statement SHOULD have the following form:: 261 4. A "while" statement SHOULD have the following form:: 262 263 while(!isDone){ 264 statements; 265 isDone = moreToDo(); 266 } 267 268 5. A "do...while" statement SHOULD have the following form:: 264 269 265 270 do{ … … 267 272 }while (condition); 268 273 269 6. a switchstatement SHOULD have the following form::274 6. A "switch" statement SHOULD have the following form:: 270 275 271 276 switch (condition){ … … 281 286 } 282 287 283 7. A try...catch...finallystatement SHOULD have the following form::288 7. A "try...catch...finally" statement SHOULD have the following form:: 284 289 285 290 try{ … … 291 296 } 292 297 293 8. Single statement if-else, while or for MUST NOT be written without298 8. A single statement if-else, while or for MUST NOT be written without 294 299 brackets, but CAN be written on the same line:: 295 300 … … 307 312 5. Semi-colons in for statements SHOULD be followed by a space. 308 313 6. Semi-colons SHOULD NOT be preceded by a space. 309 7. Functions/method calls SHOULD NOT be followed by a space. 310 ex. doSomething(someParameter); // NOT doSomething (someParameter) 314 7. Functions/method calls SHOULD NOT be followed by a space: 315 316 doSomething(someParameter); // NOT doSomething (someParameter) 317 311 318 8. Logical units within a block SHOULD be separated by one blank line. 312 319 9. Statements MAY be aligned wherever this enhances readability.
