3 ms·
Read-optimize your code
- barrkel 17y agoI'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 17y agoI 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?