style

一个开源的Flash 播放器,可以在Windows/Linux 上运行

Random thoughts on coding style/conventions:

* Hungarian Notation is a crime against programity and I will not
  mention it again.

* Scope (not type) prefixes are a different animal, and may be OK.
  For example, the common practice of prefixing member variables with
  'm_'.  I'm experimenting on a limited basis.  The 'm_' convention
  might be enough for me; I'm not sure it's useful to have prefixes
  for constants, globals (you have globals in your code? :), statics,
  etc.

  Update: I use c_ and s_ prefixes at work, and am becoming used to
  them.  Personally I think c_ is retarded; ALL_CAPS is older K&R
  approved style, more readable, and therefore better.  s_ is not bad
  though.

  g_ is not an issue -- global data is not allowed.  If that's what
  you want, just make an accessor, already.

  Summary:

     m_ for struct/class members
     s_ for statics
     ALL_CAPS for constants & macros
     no scope/type prefixes on anything else

* For me, the correct tab size will always be 8.  However, I think the
  One True Style is to not write tab size dependent code; that way
  everybody can pick their favorite tab size.  The key to this is to
  let go of trying to line things in a particular column; that's a
  maintenance nightmare anyway.  The One True Style uses tabs in two
  places only: 1) indentation, and 2) before comments on the end of
  code lines.  I'm pretty ironclad in favor of 1; 2 is debatable.
  E.g.

	for (;;) {
		// indented with tabs; pick your tab size, and enjoy.
		int a;	// *one* tab before this comment.
		bool b;	// same thing here
	}

  There's one gaping hole with this scheme, which is that indented
  paragraph comments right-justify at a tab-size dependent distance to
  the right, if your editor likes to justify at a particular column.
  Proposed solution: at some point I'll see if it's easy to make emacs
  always use 70 columns for justifying comments, starting from the
  indent rather than column 0.

  I used to put one tab after the typename in a variable declaration,
  but I've stopped doing it; it's a little too confusing for most
  programmers.

  Summary:

    tab size is 8.  Deal with it.

* Where to put the brace?  The One True Style recognizes two valid
  options:

	if (condition) {
		do stuff;
	}

or

	if (condition)
	{
		do stuff;
	}

  That ought to be enough choices for every occasion.  The GNU-esque
  abomination:

	if (condition)
	  {
	    do stuff;
	  }

  is not allowed.

* Function comments are required for anything more than a one-liner,
  and they belong between the function header and the body.  Like
  this:

	int function(int a, int b)
	// Returns a function of a and b.  Put any necessary explanation
	// here.
	{
		return a + b * a;
	}

  You can't lose them this way, and they're more likely to get used
  and maintained.

* Identifiers: I'm back to lowercase_with_embedded_underscores.  I
  wandered in the EmbeddedCaps desert for a long time, but embedded
  underscores are easier to read and type.  They take up a little more
  room, but I think it's probably worth it for the readability.  They
  don't relentlessly expose the incompatibility between case-sensitive
  and case-insensitive file systems (i.e. sloppy Windows users are
  less likely to screw up the Linux build).

* Spaces:

  * Space after comma, always.
  
  * Spaces around operators.

  * Space after 'if', 'else', 'for', 'while', 'do', always.

  * No space between the function name and the '(' to start the
    argument list -- never.

  * No extra spaces inside parentheses.  I tried this, I really
    inhaled.  It sucks -- there's no way (that I found) to do it
    consistently, without making things even more unreadable and ugly.
    Doing it inconsistently is obnoxious; too hard for others to learn
    your idiosyncratic rules.

* ~80-char lines of ///////////// or //------------ or whatever: not
  allowed.  Too much effort to maintain.  Use blank lines to delimit
  your sections.