Lines Matching refs:be
33 same module, and rely on each other non-trivial behavior, should be
34 documented as such and declared 'static'. They should be avoided if
38 meaningful names and can be easily manipulated. The only exceptions
41 or actions should be done through a #define.
43 4. When writing functions that deal with strings, be sure to remember
45 shouldn't be calculated with strlen(). Write your functions in a such
47 for efficiency and in order for them to be binary-safe.
49 doing so, should return that new length, so it doesn't have to be
78 In almost all cases, memory returned to the engine must be allocated
81 The use of malloc() should be limited to cases where a third-party
88 1. Function names for user-level functions should be enclosed with in
89 the PHP_FUNCTION() macro. They should be in lowercase, with words
91 Abbreviations should not be used when they greatly decrease the
100 (could be 'mcrypt_mod_get_algo_sup_key_sizes'?)
102 (could be 'html_get_trans_table'?)
110 be included in the user function name, and should be clearly related
111 to the parent program or function family. This should be in the form
125 3. Function names used by user functions should be prefixed
128 they should be declared 'static'.
130 4. Variable names must be meaningful. One letter variable names must be
134 5. Variable names should be in lowercase. Use underscores to separate
152 7. Classes should be given descriptive names. Avoid using abbreviations where
155 The class name should be prefixed with the name of the 'parent set' (e.g.
169 1. Functions that are part of the external API should be named
170 'php_modulename_function()' to avoid symbol collision. They should be in
171 lowercase, with words underscore delimited. Exposed API must be defined
176 Unexposed module function should be static and should not be defined in
181 2. Main module source file must be named 'modulename.c'.
183 3. Header file that is used by other sources must be named 'php_modulename.h'.
232 1. Extensions should be well tested using *.phpt tests. Read about that
255 the end of the fold, and should be on a separate line.
282 Ongoing status notes which may not be appropriate for SVN comments.
288 documentation purposes, these will only be documented by the most
292 highlight_file and show_source), will be separately documented. The
293 proto should still be included, describing which function is aliased.
295 Backwards compatible functions and names should be maintained as long
296 as the code can be reasonably be kept as part of the codebase. See
