
Read-optimize your code - nreece
http://www.brendel.com/consulting/blog/2009/06/read-optimized-source-code.html
======
barrkel
I'm not sure why, but people that use the term "not a team player" to beat
other people up really rub me the wrong way.

Perhaps its because the desired trait has no moral worth in itself. It's
application of peer pressure at its most brazen. It sounds to me like, "you're
not conforming to the group's norms", or "you're exhibiting lower than
acceptable levels of groupthink".

Anyway, I agree with naming (the most important aspect of programming style,
IMHO) and "why over how" comments. The consistent style, I'm a lot less
enamoured with. Aligned '=' assignments drive me up the wall - particularly
when there are short variables like 'i' mixed with nice long descriptive
names, where it can be hard to see what corresponds to what with the gap in
the middle. But, of such stuff wars are made.

The other argument against consistent style is archeological: style
idiosyncrasies, providing they aren't too far off the beaten track, can make
it clear at a glance who on the team modified a particular piece of code.

~~~
mgreenbe
I think he means "not a team player" in a very literal sense: if you are too
lazy to organize and document your code, you are valuing a few minutes of your
time as more important than much more of someone else's. That "someone else"
is most likely on your team.

I think that alignment and organization is important, but any formal system --
e.g., align all basic blocks of assignments -- is bound to be irritating. I
align related statements, with liberal whitespace to distinguish unrelated
sections of the same basic block.

"Why" comments are key not only on code, but on data structure definitions
also. Is that tree any old tree, a min-heap, a BST, a DAG?

