Naming
Choosing good names is critical to creating code that is easy to use and easy to understand. You should always take the time to think about whether you have chosen the right name for something, especially if it is part of the public API.
Our naming standards are mostly consistent with those of ECMAScript and Flash Player 9.
Abbreviations
Avoid them as a general rule. For example, calculateOptimalValue() is a better method name than calcOptVal().
Being clear is more important than minimizing keystrokes. And if you don't abbreviate, developers won't have to remember whether you shortened a word like “qualified” to “qual” or “qlfd”.
However, we have standardized on a few abbreviations:
- acc for accessibility, as in ButtonAccImpl
- auto for automatic, as in autoLayout
- auto for automatic, as in autoLayout
- eval for evaluate, as in EvalBindingResponder
- impl for implementation, as in ButtonAccImpl
- info for information, as in GridRowInfo
- num for number of, as in numChildren
- min for minimum, as in minWidth
- max for maximum, as in maxHeight
- nav for navigation, as in NavBar
- regexp for regular expression, as in RegExpValidator
- util for utility, as in StringUtil
This list probably does not include all abbreviations that are currently in use. If you're considering using an abbreviation that isn't listed here, please search the source code to determine whether it is already in use. If you don't find it, think twice about whether abbreviating is really appropriate.
Occasionally we are (deliberately) inconsistent about abbreviations. For example, we spell out “horizontal” and “vertical” in most places, such as horizontalScrollPolicy and verticalScrollPolicy but we abbreviate them to H and V in the very-commonly-used container names HBox and VBox.
Acronyms
Various acronyms are common in Flex, such as AIR, CSS, HLOC, IME, MX, MXML, RPC, RSL, SWF, UI, UID, URL, WSDL, and XML.
An acronym is always all-uppercase or all-lowercase (e.g., SWF or swf, but never Swf). The only time that all-lowercase is used is when the acronym is used by itself as an identifier, or at the beginning of an identifier, and the identifier should start with a lowercase letter. See the rules below for which identifiers should start with which case.
Examples of identifiers with acronyms are CSSStyleDeclaration, IUID, uid, IIME, and imeMode.
Word boundaries
When an identifier contains multiple words, we use two ways of indicating word boundaries: intercaps (as inLayoutManager or measuredWidth) and underscores (as in object_proxy). See the rules below for which method to use.
Sometimes it isn't clear whether a word combination has become its own single word, and we are unforunately inconsistent about this in some places: dropdown, popUp, pulldown.
Follow the acronym-casing rules even in the rare case that two acronyms must be adjacent. An example (which isn't actually in use) would be something like loadCSSURL(). But try to avoid such names.
Type-specifying names
If you want to incorporate the type into the name, make it the last “word”. Don't use the old ActionScript 1 convention of concatenating abbreviated type suffixes such as _mc to indicate type. For example, name a border Shape border,borderSkin, or borderShape, but not border_mc.
Often, the best name for an object is simply the same as its type, with different casing:
Package names
Start them with a lowercase letter and use intercaps for subsequent words: controls, listClasses.
Package names should always be nouns or gerunds (the -ing noun form of a verb), not verbs, adjectives, or adverbs.
A package implementing lots of similar things should have a name which is the plural form of the thing: charts,collections, containers, controls, effects, events, formatters, managers, preloaders, resources, skins, states, styles, utils,validators.
It is common to use a gerund for the name of a package which implements a concept: binding, logging, messaging, printing. Otherwise, they are generally "concept nouns": accessibility, core, graphics, rpc.
A package containing classes that support component FooBar should be called fooBarClasses.
File names
For importable APIs, the file name must be the same as the public API inside. But include files don't have to follow this rule.
Start the names of include files for [Style(...)] metadata with an uppercase letter, use intercaps for subsequent words, and make the last word “Styles”: BorderStyles.as, ModalTransparencyStyles.as.
Start the names of individual asset files with a lowercase letter and use underscores between words:icon_align_left.png.
Namespace names
Start them with a lowercase letter and use underscores between words: mx_internal, object_proxy.
Interface names
Start them with I and use intercaps for subsequent words: IList, IFocusManager, IUID.
Class names
Start them with an uppercase letter and use intercaps for subsequent words: Button, FocusManager, UIComponent.
Name Event subclasses FooBarEvent.
Name Error subclasses FooBarError.
Name the EffectInstance subclass associated with effect FooBar FooBarInstance.
Name Formatter subclasses FooBarFormatter.
Name Validator subclasses FooBarValidator.
Name skinning classes FooBarBackground, FooBarBorder, FooBarSkin, FooBarIcon, FooBarIndicator, FooBarSeparator, FooBarCursor, etc.
Name utility classes FooBarUtil (not FooBarUtils; the package is plural but the class is singular).
It is common to name a base class FooBarBase: ComboBase, DateBase, DataGridBase, ListBase.
Event names
Start them with a lowercase letter and use intercaps for subsequent words: "move", "creationComplete".
Style names
Start them with a lowercase letter and use intercaps for subsequent words: color, fontSize.
Enumerated values for String properties
Start them with a lowercase letter and use intercaps for subsequent words: "auto", "filesOnly",
Constant names
Use all uppercase letters with underscores between words: OFF, DEFAULT_WIDTH.
The words in the identifier must match the words in the constant value if it is a String:
Property (variable and getter/setter) names
Start them with a lowercase letter and use intercaps for subsequent words: i, width, numChildren.
Use i for a loop index and n for its upper limit. Use j for an inner loop index and m for its upper limit.
Use p (for “property”) for a for-in loop variable:
If a class overrides a getter/setter and wants to continue to expose the base getter/setter, it should do so by implementing a property whose name is the base name with a $ prepended. This getter/setter should be marked finaland should do nothing more than call the supergetter/setter.
Storage variable names
Give the storage variable for the getter/setter foo the name _foo.
Method names
Start them with a lowercase letter and use intercaps for subsequent words: measure(), updateDisplayList().
Method names should always be verbs.
Parameterless methods should generally not be named getFooBar() or setFooBar(); these should be implemented as getter/setters instead. However, if getFooBar() is a slow method requiring a large amount of computation, it should be named findFooBar(), calculateFooBar(), determineFooBar(), etc. to suggest this, rather than being a getter.
If a class overrides a method and wants to continue to expose the base method, it should do so by implementing a method whose name is the base name with a $ prepended. This method should be marked final and should do nothing more than call the supermethod.
Event handler names
Event handlers should be named by concatenating “Handler” to the type of the event: mouseDownHandler().
If the handler is for events dispatched by a subcomponent (i.e., not this), prefix the handler name with the subcomponent name and an underscore: textInput_focusInHandler().
Argument names
Use value for the argument of every setter:
Do this:
Not this:
Or this:
Or this:
Use event (not e, evt, or eventObj) for the argument of every event handler:
Resource bundle names
If a resource bundle contains resources for a particular package, name the bundle the same as the package: controls, {formatters}}, validators.
Resource key names
Start them with a lowercase letter and use intercaps for subsequent words: pm, dayNamesShort.
Miscellaneous nomenclature
Avoid “object” because it is vague.
An “item” is a data item, not a DisplayObject.
A “renderer” is a DisplayObject that displays a data item.
A “type” is an AS3 type; use "kind" otherwise.
Language Usage
This section discusses how we use the language constructs of ActionScript 3, especially when there are multiple ways to express the same thing.
Compilation options
Compile with the options -strict and -show-actionscript-warnings. (These are the defaults in the flex-config.xml file.)
Property-based APIs
Favor property-based APIs rather than method-based APIs, because these are more suitable for declarative-style MXML programming.
Type declarations
Write a type annotation for every constant, variable, function argument, and function return value, even if the annotation is simply :* to indicate “no type”.
Do this:
Not this:
Use the narrowest type that is appropriate. For example, a loop index should be a int, not a Number, and certainly not anObject or *. As another example, a mouseDownHandler should declare its argument as event:MouseEvent, not event:Event.
Use int for integers, even if they can't be negative. Use uint only for RGB colors, bit masks, and other non-numeric values.
Use * only if the value can be undefined. You should generally use Object rather than *, with null being the “object doesn't exist” value.
If you declare something to be of type Array, add a comment of the form /* of ElementType */ immediately after Arrayindicate the type of the array elements. A future version of the language is likely to have typed arrays.
Do this:
Not this:
And this:
Not this:
Literals
undefined
Avoid using this when possible. It is only necessary when dealing with values whose compile-time is type is *, and you should be using * sparingly as well.
int and uint literals
Do not use a decimal point in a integer.
Do this:
Not this:
Use a lowercase x and uppercase A-Z in hexadecimal numbers.
Do this:
Not this:
Always write an RGB color as a six-digit hexadecimal number.
Do this:
Not this:
When dealing with indices, use the value -1 to mean “no index”.
Number literals
If a Number value typically can be fractional, indicate this by using a decimal point, and follow the decimal point by a single trailing zero.
Do this:
Not this:
However, don't do this for pixel coordinates, which are by convention integral even though they can in principle be fractional.
Do this:
Not this:
Use e, not E, when using exponential notation.
Do this:
Not this:
Use the default value NaN as the “not set” value for a Number.
String literals
Use quotation marks (double quotes), not apostrophes (single quotes), to delimit strings, even if that string contains a quotation mark as a character.
Do this:
Not this:
Use \u, not \U, for unicode escape sequences.
Array literals
Use Array literals rather than new Array().
Do this:
Not this:
And this:
Not this:
Use the Array constructor only to allocate an array of a prespecified size, as in new Array(3), which means [ undefined, undefined, undefined ], not [ 3 ].
Object literals
Use Object literals rather than new Object().
Do this:
font-weight: normal; font-size: 11px; margin: 16
分享到:
Global site tag (gtag.js) - Google Analytics
|
相关推荐
C++ Coding Standards: 101 Rules, Guidelines, and Best Practices,英文版。C++ In-Depth系列丛书之一,C++程序员必看。
The second edition of this book not only sheds light on Django, but also encapsulates years of experience in the form of design patterns and best practices. Rather than sticking to GoF design ...
[由于只能上传的文件,本资料分四次共享,大家一定要把C++高级参考手册Part 1 +Part 2 +Part 3+ Part4 下载完整,便可解压~ 不便之处朋友谅解! 两位知名的C++专家(Herb Sutter & Andrei Alexandrescu)将全球C++界...
Since the ideas and concepts are described in simple terms, no previous experience in computer coding or programming is required. What You Will Learn Control Selenium WebDriver within any major ...
Secure Coding: Principles & Practices looks at the problem of bad code in a new way. Packed with advice based on the authors' decades of experience in the computer security field, this concise and ...
C++ Coding Standards,101 Rules,Guidelines and Best Practices(Herb Sutter)
Perl Best Practices author Damian Conway explains that rules, conventions, standards, and practices not only help programmers communicate and coordinate with one another, they also provide a reliable...
代码规范,很有名的,就不要积分了,随便用吧.
Chapter 2 is about syntax best practices, below the class level. It presents iterators, generators, descriptors, and so on, in an advanced way. Chapter 3 is also about syntax best practices, but ...
Learn software engineering and coding best practices to write Python code right and error free. In this book you’ll see how to properly debug, organize, test, and maintain your code, all of which ...
Chapter 9: Best Practices for Function-Based Views Chapter 10: Best Practices for Class-Based Views Chapter 11: Form Fundamentals Chapter 12: Common Patterns for Forms Chapter 13: Templates: Best ...
Perl Best Practices author Damian Conway explains that rules, conventions, standards, and practices not only help programmers communicate and coordinate with one another, they also provide a reliable...
Oracle PL/SQL Best Practices Preface When I first started writing about the Oracle PL/SQL language back in 1994, the only sources of information were the product documentation (such as it was) and ...
book talks about a lot of best practices that quite often are missed by developers while coding. The book also covers many design patterns. Design patterns are nothing but best practices to solve ...
Design and architect real-world scalable C++ applications by exploring advanced techniques in low-level programming, object-oriented programming (OOP), the Standard Template Library (STL), ...
We'll take you through multithreading design patterns, such as master, slave, leader, follower, map-reduce, and monitor, also helping you to learn hands-on coding using these patterns. Once you've ...
S60 Platform C++ Coding Conventions Version 2.0.pdf
Symbian OS Coding Conventions in C++ Version 1.0.pdf
Secure Coding - Principles & Practices