Date: Fri, 28 Feb 2003 09:05:50 -0800 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Jason Andresen <jandrese@mitre.org>, hackers@freebsd.org Subject: Re: C coding editor Message-ID: <200302280905.50452.wes@softweyr.com> In-Reply-To: <3E5F85B3.268BD21C@mindspring.com> References: <20030221122103.GA2073@asterix.local> <200302272324.56873.wes@softweyr.com> <3E5F85B3.268BD21C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 28 February 2003 07:52, Terry Lambert wrote:
>
> I blame this on people unsuited to writing software getting CS
> degrees and/or programming jobs, because they think that that's where
> the money is at. Luckily, they later find out that salary is a
> matter of merit, much more than it's a matter of having paper
> credentials, and if you haven't blown at least one test because you
> wer in the CS lab until 5AM playing with the new Retrogrpahics cards
> and high persistance phosphor tubes, and slept through your alarm,
> well... 8-) 8-).
Oh, the good old days.
> Very soon, these people end up finding gainful
> employment asking people if they would like fries with that.
Just like RMS wants them too. But wait, he wants you and me to be doing
that too...
> I personally attribute the majority of very long lines to deep
> structure element nesting, which everyone seems happy to do these
> days, and long_variable_names_which_try_to_be_meaningful_but_fail.
> Hell, you can't add two of those together, even with a "+=", and
> not wrap the line at least once...
Ditto. I have a single function, the critical path of the Xylan switch
control software, that fits nicely in 80 columns. It has a McCabe's
complexity number of 360, the highest I've ever heard of. According to
McCabe, anything beyond 25 is not understandable by human beings and
it's a logarithmic scale.
> > No, but your editor really ought to be able to interpret tab stops
> > correctly at like 0.5 in increments. Code editors on the Mac have
> > been doing this for years.
>
> If editors like this were more common, it would be a lot easier to
> justify use of proportional fonts in coding editors. I don't think
> anyone really cares how many characters there are after a tabstop,
> so long as the visual layout is uniform to the left of the code. If
> you use indentation, this still works, no mater what your font, as
> long as there are fixed indentations per tab (IMO).
Precisely. The GNU enscript pretty-print function does a relatively
nice job of this, but it ends up mangling the gnu-style continuation
line indents. Solution? Don't do continuation lines. At all. Just
print your code 1-up in 7 point Palatino and it fits nicely on
Letter-size paper. For those of us weird enough to print code, that
is.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302280905.50452.wes>