Skip site navigation (1)Skip section navigation (2)
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>