- These are meant to be descriptive, not dictatorial; I won't
- presume to tell you how to program, I'm just describing the
- methods I chose to use for myself. If you do choose to
- follow these guidelines, it will probably be easier for you
- to collaborate with others on the project, but if you want
- to contribute without bothering, by all means do so (and don't
- be surprised if I reformat your code).
-
- - I have the code indented with tabs to save file size and
- so that users can set their tab stops to any depth they like.
- I use 4-space tab stops, which work well. I also use K&R brace
- matching style. I know that's a religious issue for some,
- so if you want to use a style that puts opening braces on the
- next line, that's OK too, but please don't use a style where
- closing braces don't align with either the opening brace on
- its own line or the statement that opened the block--that's
- confusing as hell.
-
- - PHP doesn't have "private" member variables of functions,
- so I've used the comment "/* private */" in some places to
- indicate my intent. Don't access things marked that way
- from outside the class def--use the accessor functions (or
- make your own if you need them). Yes, even some globals
- are marked private, because PHP is broken and doesn't
- allow static class variables.
-
- - Member variables are generally "mXxx" to distinguish them.
- This should make it easier to spot errors of forgetting the
- required "$this->", which PHP will happily accept by creating
- a new local variable rather than complaining.
-
- - Globals are particularly evil in PHP; it sets a lot of them
- automatically from cookies, query strings, and such, leading to
- namespace conflicts; when a variable name is used in a function,
- it is silently declared as a new local masking the global, so
- you'll get weird error because you forgot the global declaration;
- lack of static class member variables means you have to use
- globals for them, etc. Evil, evil.
-
- I think I've managed to pare down the number of globals we use
- to a scant few dozen or so, and I've prefixed them all with "wg"
- so you can spot errors better (odds are, if you see a "wg"
- variable being used in a function that doesn't declare it global,
- that's probably an error).
-
- Other conventions: Top-level functions are wfFuncname(), names
- of session variables are wsName, cookies wcName, and form field
- values wpName ("p" for "POST").
-
- - Be kind to your release manager and don't use CVS keywords (Id,
- Revision, etc.) to mark file versions. They make merging code
- between different branches a pain for CVS, and are kind of sketchy
- for versions after that. (Yes, you can use the '-kk' flag so that
- merges ignore keywords, but that messes up binary files. See
- https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_5.html#SEC64).
-
-
-
\ No newline at end of file
+ These are meant to be descriptive, not dictatorial; I won't presume to tell
+ you how to program, I'm just describing the methods I chose to use for myself.
+ If you do choose to follow these guidelines, it will probably be easier for
+ you to collaborate with others on the project, but if you want to contribute
+ without bothering, by all means do so (and don't be surprised if I reformat
+ your code).
+
+ - I have the code indented with tabs to save file size and so that users can
+ set their tab stops to any depth they like. I use 4-space tab stops, which
+ work well. I also use K&R brace matching style. I know that's a religious
+ issue for some, so if you want to use a style that puts opening braces on
+ the next line, that's OK too, but please don't use a style where closing
+ braces don't align with either the opening brace on its own line or the
+ statement that opened the block--that's confusing as hell.
+
+ - Certain functions and class members are marked with /* private */, rather
+ than being marked as such. This is a hold-over from PHP 4, which didn't
+ support proper visibilities. You should not access things marked in this
+ manner outside the class/inheritance line as this code is subjected to be
+ updated in a manner that enforces this at some time in the near future, and
+ things will break. New code should use the standard method of setting
+ visibilities as normal.
+
+ - Globals are particularly evil in PHP; it sets a lot of them automatically
+ from cookies, query strings, and such, leading to namespace conflicts; when
+ a variable name is used in a function, it is silently declared as a new
+ local masking the global, so you'll get weird error because you forgot the
+ global declaration; lack of static class member variables means you have to
+ use globals for them, etc. Evil, evil.
+
+ I think I've managed to pare down the number of globals we use to a scant
+ few dozen or so, and I've prefixed them all with "wg" so you can spot errors
+ better (odds are, if you see a "wg" variable being used in a function that
+ doesn't declare it global, that's probably an error).
+
+ Other conventions: Top-level functions are wfFuncname(), names of session
+ variables are wsName, cookies wcName, and form field values wpName ("p" for
+ "POST").