Lines Matching refs:should
6 code in PHP should follow. Since this file was added at a very late
17 1. Functions that are given pointers to resources should not free them
19 For instance, ``function int mail(char *to, char *from)`` should NOT free
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
41 or actions should be done through a #define.
49 doing so, should return that new length, so it doesn't have to be
69 existing. End users should use function_exists() to test for the
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
109 2. If they are part of a "parent set" of functions, that parent should
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'.
134 5. Variable names should be in lowercase. Use underscores to separate
152 7. Classes should be given descriptive names. Avoid using abbreviations where
153 possible. Each word in the class name should start with a capital letter,
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
176 Unexposed module function should be static and should not be defined in
226 indent preprocessor directives you should put the # at the beginning
232 1. Extensions should be well tested using *.phpt tests. Read about that
239 the code, each user-level function should have its user-level function
255 the end of the fold, and should be on a separate line.
278 The file labelled 'EXPERIMENTAL' should include the following
284 In general new features should go to PECL or experimental branches until
296 proto should still be included, describing which function is aliased.
298 Backwards compatible functions and names should be maintained as long
