[gdulli]

These things turn subjective pretty quickly. That, and, "this is the way most people do it, so just do it this way."

[collyw]

Sometimes I find guidelines like these counterproductive.

For example, when looking through someone elses code, if it does not have deep levels of nesting I prefer longer methods you can read like a script rather than having to jump around the place to see what is each method.

Likewise with the 80 character guideline in PEP. It can take a lot longer to find the closing brace if it is hidden in columns that look like a newspaper article.

[bru]

>Likewise with the 80 character guideline in PEP

Definitely. The PEP8 was actually revised 6 months ago[0]. Nothing crazy, but a bit more pragmatic.

>For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters)

0: text: http://legacy.python.org/dev/peps/pep-0008/#maximum-line-len...

commit : http://hg.python.org/peps/rev/fb24c80e9afb

[nine_k]

I think this is due to poor naming, not due to short functions.

Compare:

  def makeMove(self, target):
    enemy_piece = target.piece
    if enemy_piece:
      self.takeEnemyPiece(enemy_piece)
    target.piece = self
    self.position = target

And

  def changeCoords(self, foo):
    if foo.standing_on_it:
      self.nowItsMine(foo.standing_on_it)
    foo.standing_on_it = self
    self.coords = foo

In the former case, you mostly don't need to consult the source of functions called. In the latter, you're never sure.

[gdulli]

Yes. I look at these things and pick out what I think are the good parts.