Re: coding style

[Donn Cave <donn@u.washington.edu>]

|	if (
|		{~ $#TERM 0 || ~ $TERM ''}	{ TERM = unknown }
|		{~ $TERM *' '*}			{ TERM = <>{%flatten - <>{%split ' ' $TERM}} }
|		{~ $TERM *vt520}		{ TERM = vt52 }
|	)

Whew, that's much better.  I broke the "then" clauses onto new lines, because
multi-column code is too much work for me to keep aligned.  That leaves only
the relatively trivial issue of where to put the brackets surrounding a block
with more than one line.

| steve's suggestion, which i love & endorse is to take advantage of the fact that
| within parens, newlines are treated just as spaces, so we don't need to use the
| hanging braces (open brace at end of line) to continue a line.  this could be
| written even more lispish as
|	(if
|		...
|	)
| but i think that that obfuscates rather than elucidates.

I'm not too offended by it.  It has the advantage of being more obviously
independent of "if", that is, one could see "if (" and think ``Oh, right,
the "if (foo) {bar}" statement, I know it well.''

| two notes:  (1) i recommend against using %or and %and unless you really
| want them.  if is usually more clear.

Right, I just missed the implicit "else" in "if", 

|	i tend to try to stay away from using % commands except
| when redefining them or a few other special purposes.  && and || work in es, and
| %or and %and are mainly around to support that funky syntax.  (2) i'm not sure
| that my TERM setting code above does exactly what yours did---i tend to not like
| using eval.  here i go against what i recommended earlier this paragraph and
| used %flatten and %split, because there is no syntax to access them directly.

It does, and I don't particularly either.  Minutes later I got onto that one
myself.  I was using "eval" in the rc code this was based on.

I see that there's also an "fsplit"?

	Donn Cave, University Computing Services, University of Washington
	donn@cac.washington.edu