Re: Re: convention about function naming II

At 01:40 PM 12/18/00 -0700, Ron Chmara wrote:

André Langhorst wrote: I have searched through almost all extensions and discovered the following things: 1) a) is it proposed that experimental extensions *always* have to prefix their names and ought to put an EXPERIMENTAL file into their folder? if not I think it would make sense Prefixes are the standard. php4/CODING_STANDARDS "It they are part of a parent set, that parent should be included in the user function name" I havn't seen any notes on the EXPERIMENTAL file. b) is anywhere defined if ext_* or ext* is the preferred naming, currently both are mixed up, I find ext_* more readable See above. Imposing a standard like this, later in the game, means that as we upgrade ext's, we have to maintain aliases, and rename them... it's implied by the examples, but it's not explicitly stated to use ext_*, just taht words are to be underscore-delimited. c) I would suggest not to use very long function names to make people angry eg. "filepro","ingres","opensll","ovrimos","satellite" - I personally prefer using "fp","ingr","ossl","ovr" or "sat" is there any convention about this? See above. "With care taken to minimze the letter count". It's not real specific, though, as the ruleset could quickly become difficult to manage... (no vovels, unless begun with a vowel, in which case an opening vowel, unless it's all vowels, 4 or less letters, unless there's a very similar four letters... etc. etc.). When I wrote the above, the idea was to leave it at the coder's discretion, with an instruction to consider shortened versions. It certainly couldn't hurt to add more examples and clarifications to the above, as well as sprinkle some more notes on these conventions in the appropriate places.

We have said that people shouldn't try to shorten the prefix in order to save typing (unless it's really a bad name). Good example is ingress which was "ii" and was asked to move to "ingres", "ingr" would have been pretty ugly and unreadable. Andi --- Andi Gutmans <andi@zend.com> http://www.zend.com/