Re: [Webware-devel] SpacesNotTabs debate raging on comp.lang.python

[Ian B. <ia...@co...>]

On Fri, 2001-12-07 at 18:58, Chuck Esterbrook wrote:
> On Friday 07 December 2001 02:30 pm, Ian Bicking wrote:
> > I've also found that as long as I leave the tabwidth at 8, the
> > auto-tab-detection works correctly -- i.e., Emacs inserts tabs in
> > files that use tabs, and spaces in files that use spaces.  I don't
> > know why it doesn't work with a tabwidth of 4.
> >
> [snip]
> >
> > The '''-quoted doc strings are still also a problem for Emacs.
> 
> Psuedo-radical thoughts:
> 
> - Since emacs' auto-tab-detection almost works except when tabwidth is 
> 4, would it be possible to fix emacs?

Probably.  Since the autodetection works fine, and all of my own code
uses 4 spaces, I'm not as concerned.  Not enough to go browsing through
the elisp looking for a bug -- and probably one that's subtle, since it
interacts with something deep in Emacs (the width that tabs are
displayed at).

> - Since emacs already handles multi-line strings with double quotes, 
> would it be possible to fix it to handle multi-line strings with single 
> quotes?

Double quotes work the same as single: the difference is that single
quotes are often not matched inside a doc string, e.g., '''don't use
this'''.  Changing ''' to """ should be easy, and it pretty much fixes
this.

> > * Absolutely wrap lines before 90 (particularly docstrings).  The
> > current codebase is absolutely full of run on lines.
> 
> Hmm, I'm inclined to let code lines run a little longer, say 130. We 
> presumably all have wide windows when doing serious development and 
> most editors allow wrapping or non-wrapping as you like.

I use 80-columns.  It's leaves me just a tiny bit shy of being able to
have two windows side-by-side.  80 is conventional.  Most lines easily
fit in under 80, so if you use 130 you're just going to have a lot of
empty space on your screen.

In an endline-sensitive language, wrapping *can't* be as pretty as
manually putting in newlines -- if it was, you wouldn't be able to tell
that there were semantic differences in some instances.  In the case of
Emacs, wrapped lines get cut off at exactly 80 (or whatever width your
window is), without any attention to word boundaries.  I imagine lots of
editors are the same -- and if they *aren't* like that, I'd be afraid of
damaging my code by not realizing where the newlines were.

> > * Include a blank line before and after every docstring.  This makes
> > it much easier to re-wrap the docstrings when the content changes.

Even in my own code, I usually insert the newline, wrap, and remove it
again, despite the inconvenience.  I don't like having excessive
vertical whitespace -- M-Up and M-Down work better if you have just the
right amount of whitespace.

> > * If a method of function has lots of args list them one or two
> > per-line, instead of having a huge run-on line.
> 
> Does "lots of args" mean past a certain column number or what?

I think there's a justification for long lines when you are doing lots
of composition of functions or something -- at least indenting the way
Emacs does, it is often no advantage to split lines.  But when you have
lots of arguments it's really easy to split lines, so why not?

e.g., this will often go over 80 columns and is hard to fix:

self.myInstanceVar = self.namespace().getVar(self.findVarName(self.request().field('fieldName', None))))

Some might say temporary variables are called for, or it's bad
programming style... but I tend to do this sort of thing quite often,
and there's no decent way of splitting that line to shorten it.

  Ian