Post length for code.

[name]

One imagines that code over a certain length should be put on a website and
the URL posted here. However, one also imagines that some readers will not
have a web browswer available; posting a URL only will not serve such readers.

My wee program is approaching 200 lines. Is that too long to post here?

Thanks for reading.

 

[Arthur J. O'Dwyer]

One imagines that code over a certain length should be put on a website
and the URL posted here. However, one also imagines that some readers
will not have a web browswer available; posting a URL only will not
serve such readers.

My wee program is approaching 200 lines. Is that too long to post here?

IMHO, it's not so much the length of the program that matters. I mean,
obviously shorter is better (as far as Usenet is concerned), but we have
seen English-text articles here running into the 50K-90K range. 200 lines
of C code is short by comparison.

What you need to consider is whether your posting the code here is
going to make life easier or harder for the people who want to communicate
with you. If you post 200 lines of code with only one "problem section,"
then most responses will have to snip out about 190 lines; whereas if you
post the same thing on a website, most respondents will have to
cut-and-paste only 10 lines. OTOH, if your program still has errors on
every line, a line-by-line response might be helpful---in that case, it
makes sense to post the program directly to Usenet.

Besides the relative ease of quoting posted or uploaded code, you
should also consider the ease of compiling that code. If a piece of
code fits on one screen of my newsreader, I can cut-and-paste it into
a source file directly; otherwise, I have to export the whole message
and trim the headers and extraneous message text by hand. But if you
post the code to a website, it's just 'wget http://bar.com/foo.c'
and I'm ready to compile.

Finally, obviously you need to consider your access to web-uploading.
If you don't have a website, it's kind of a moot point, isn't it? And
if you have the server space to spare, IMHO it makes sense to do both:
post the code /and/ upload a copy to the Web for people who like that
better.

There's no hard-and-fast rule. Just use common sense.

HTH,
-Arthur

 

[CBFalconer]

One imagines that code over a certain length should be put on a
website and the URL posted here. However, one also imagines that
some readers will not have a web browswer available; posting a
URL only will not serve such readers.

My wee program is approaching 200 lines. Is that too long to
post here?

Not really, provided it is cleanly formatted, doesn't use tabs,
and lines don't exceed about 65 chars. Also that it is in
standard C.

 

[name]

Not really, provided it is cleanly formatted, doesn't use tabs,
and lines don't exceed about 65 chars. Also that it is in
standard C.

Well, I limit them to 75, but most are less than that by a good bit.
Problem is, I use tabs! What is the problem with tabs?

In any case, guess I'll put it on the site and post the URL; I suppose
anyone reading here has wget or the equivalent (lynx?). That'll be
interesting...

But I still would like to know about tabs!

Thanks for reading...

 

[Mike Wahler]

Well, I limit them to 75, but most are less than that by a good bit.
Problem is, I use tabs! What is the problem with tabs?

They won't appear the same for everyone (there's no 'standard'
tab width). And some newsreaders filter them out completely,
wrecking your formatting.

In any case, guess I'll put it on the site and post the URL; I suppose
anyone reading here has wget or the equivalent (lynx?). That'll be
interesting...

I'd find it unusual (but not out of the question) for someone
who has Usenet client software to not also have a web browser.
Another alternative is FTP.

But I still would like to know about tabs!

See above.

-Mike

 

[Derrick Coetzee]

But I still would like to know about tabs!

My viewpoint on this matter is a bit extreme:

Don't ever, ever, use tabs in source code. Ever. Not in production code,
not in test code, not in quick learning code, not in sample code, not in
any language, not on any platform, regardless of your company's style
standards, just don't do it.

Why not? Because you gain nothing at all but a few bytes of space, while
causing your code to look terrible in any editor using a different tab
width, making the code more difficult to edit, and making your code
samples go off the edges of people's windows. In particular, it makes it
impossible to line up //-style line comments in all editors.

'But it's not my fault,' you say, 'My editor inserts them!' Well, here's
how to make it stop doing so:

* Visual Studio .NET: Tools->Options->Text Editor->
All Languages->Tabs->Insert spaces
* Emacs:
Temporarily: M-x set-variable<RET> indent-tabs-mode<RET> nil<RET>
Permanently: (setq-default indent-tabs-mode nil) # put in ~/.emacs

* Vi: set softtabstop = 2
set expandtab

If you have existing files with tabs, you can kill them using various
utilities, such as the Emacs M-x untabify command.

Here are some more more resources on why tabs are bad:
* http://www.adamspiers.org/computing/why_no_tabs.html
* http://www.jwz.org/doc/tabs-vs-spaces.html

Of course, 'make' is an exception.

 

[name]

My viewpoint on this matter is a bit extreme:

<snip>

Thanks for the explanation. You probably don't want to look at my code, as
I adhere to the [tab|8_space] indent of K&R. I will, however, check out the
softtab routines. Thanks for that!

Of course, 'make' is an exception.

As are others.

BTW, why do you consider venue specific matters to be off topic? My
question was intended for the readers of this newsgroup, and so far as I
know, newsgroup specific subjects are always topical. Am I wrong?

Thanks for reading.

 

[Derrick Coetzee]

>
As are others.

You know of other languages that specifically require tab characters?

BTW, why do you consider venue specific matters to be off topic?

I wasn't saying your question was off-topic, but that my response was,
since it was just a rant about tabs. Sorry for the confusion.

 

[Chris Torek]

[reasons not to use tabs, and how to cause various editors not to
use them automatically]

Thanks for the explanation. You probably don't want to look at my code, as
I adhere to the [tab|8_space] indent of K&R. I will, however, check out the
softtab routines. Thanks for that!

I, on the other hand, have no problem at all with "hard" (\t) tabs.
They should simply always *ALWAYS* display as "every 8th column"
(columns 1, 9, 17, etc., given the silly 1-origin instead of 0-origin
numbering on typical teletype / ADM-3 "glass-tty" / H19 / xterm /
whatever). If you want some other indentation -- such as "every
4th character" -- you tell your editor to do that, and it does
that, still leaving the "hard" tabs set at every 8th position.
(In vi, ":set shiftwidth=<number>", then use ^T and ^D to indent
and de-indent, and of course the << and >> commands as usual.)

Then, for posting to newsgroups, I just run the code through the
"expand" program on Unix-like systems. (I edited Pnews.sh to do
this for me, so that I need not remember to do it manually.)

In other words, if you do not like 8-character indentation, move
the indentation, not the action of the \t character. Then, before
dumping the bytes to a system that may use something other than
8-character tabs, expand the tabs to blanks.

 

[Keith Thompson]

'But it's not my fault,' you say, 'My editor inserts them!' Well, here's
how to make it stop doing so: [...]
* Vi: set softtabstop = 2
set expandtab

That's specific to vim. Other vi clones don't support softtabstop or
expandtab (unless they're also vim clones).

Both emacs and vi (and clones) have commands to filter a region of the
buffer through an external program. On Unix-like systems, the
"expand" command expands tabs to spaces. I have a vi key map that
lets me filter the entire buffer through "expand" with a couple of
keystrokes.

 

[name]

On 2004-09-03, Derrick Coetzee <[email protected]> wrote:

[reasons not to use tabs, and how to cause various editors not to
use them automatically]

Thanks for the explanation. You probably don't want to look at my code, as
I adhere to the [tab|8_space] indent of K&R. I will, however, check out the
softtab routines. Thanks for that!

I, on the other hand, have no problem at all with "hard" (\t) tabs.
They should simply always *ALWAYS* display as "every 8th column"
(columns 1, 9, 17, etc., given the silly 1-origin instead of 0-origin
numbering on typical teletype / ADM-3 "glass-tty" / H19 / xterm /
whatever). If you want some other indentation -- such as "every
4th character" -- you tell your editor to do that, and it does
that, still leaving the "hard" tabs set at every 8th position.
(In vi, ":set shiftwidth=<number>", then use ^T and ^D to indent
and de-indent, and of course the << and >> commands as usual.)

Then, for posting to newsgroups, I just run the code through the
"expand" program on Unix-like systems. (I edited Pnews.sh to do
this for me, so that I need not remember to do it manually.)

In other words, if you do not like 8-character indentation, move
the indentation, not the action of the \t character. Then, before
dumping the bytes to a system that may use something other than
8-character tabs, expand the tabs to blanks.

Ah... Mr. Torek has the solution. I shall "expandify" my code before
posting either to the newsgroup or to my site.

Thanks to all for all this information!

 

[CBFalconer]

.... snip ...

In other words, if you do not like 8-character indentation, move
the indentation, not the action of the \t character. Then, before
dumping the bytes to a system that may use something other than
8-character tabs, expand the tabs to blanks.

For windoze/msdos users here is the help output for a utility I
wrote some time ago, and whose source I have lost. It is about
10k of code. If you want the executable let me know. Input line
lengths are limited to about 250 IIRC.

Indenting source by units of 8 is anathema to me. It leads to
running off the right. 3 or 4 is much more reasonable.

[1] c:\4dos\602>detab
DETAB copyright (c) 1989 by C.B. Falconer. Ver 1.0

usage: DETAB [tablist] <infile >outfile
If tablist is omitted a tab interval of 8 is assumed
If tablist has only one number, then that is the tab interval
If tablist contains multiple numbers, separated by spaces,
then they are assumed to be the tab points. The leftmost
column is numbered 0.
If tablist is a single 0, then tabs are not expanded
Backspaces in a line shut off tab expansion until cr

Any isolated lf's are converted into cr/lf pairs (Unix files)
Omitting the "<infile" causes this help screen

 

[Mike Wahler]

My viewpoint on this matter is a bit extreme:

Don't ever, ever, use tabs in source code. Ever. Not in production code,
not in test code, not in quick learning code, not in sample code, not in
any language, not on any platform, regardless of your company's style
standards, just don't do it.

I completely agree, and don't feel this attitude is 'extreme'
at all, but simply practical. I do indeed use the convenience
of the 'tab' key for indentation, but I configure my editors
to convert tabs to spaces.

-Mike

 

[Arthur J. O'Dwyer]

(Good advice, but there are lots of non-*nix tools and non-home
environments that define tabs to different widths. This summer I
used MSVC++ with 4-space tabs. The solution is still the same, though:
just detab the source before putting it anywhere it could be seen by
people using different tabstops.

For windoze/msdos users here is the help output for a utility I
wrote some time ago, and whose source I have lost. It is about
10k of code. If you want the executable let me know. Input line
lengths are limited to about 250 IIRC.

Indenting source by units of 8 is anathema to me. It leads to
running off the right. 3 or 4 is much more reasonable.

[1] c:\4dos\602>detab
DETAB copyright (c) 1989 by C.B. Falconer. Ver 1.0

Well, join the club!
http://www.contrib.andrew.cmu.edu/~ajo/free-software/detab.c

Looks like both of our detabbing tools are very similar to 'expand',
though. I hadn't even known 'expand' existed, before this thread.
Guess I'll have to find more bells and whistles to add to my version. ;-D

I've got a couple of tangential questions about your program, though,
if you remember anything about the implementation...

[...]

Backspaces in a line shut off tab expansion until cr

Interesting spec. Do you remember why you did it this way? Under
what circumstances would you be detabbing a file with embedded
backspaces?

[...]

Omitting the "<infile" causes this help screen

And how does this work? (Assuming '<' is a special shell character
for redirection, not something that would show up in 'argv' directly.)

-Arthur

 

[CBFalconer]

. snip ...

For windoze/msdos users here is the help output for a utility I
wrote some time ago, and whose source I have lost. It is about
10k of code. If you want the executable let me know. Input line
lengths are limited to about 250 IIRC.

Indenting source by units of 8 is anathema to me. It leads to
running off the right. 3 or 4 is much more reasonable.

[1] c:\4dos\602>detab
DETAB copyright (c) 1989 by C.B. Falconer. Ver 1.0

Well, join the club!
http://www.contrib.andrew.cmu.edu/~ajo/free-software/detab.c

Looks like both of our detabbing tools are very similar to
'expand', though. I hadn't even known 'expand' existed, before
this thread. Guess I'll have to find more bells and whistles to
add to my version. ;-D

I've got a couple of tangential questions about your program,
though, if you remember anything about the implementation...

[...]

Backspaces in a line shut off tab expansion until cr

Interesting spec. Do you remember why you did it this way?
Under what circumstances would you be detabbing a file with
embedded backspaces?

It was simply too much trouble to keep track. It might backspace
over tab characters, and should I assume they were expanded before
or after, which depends on the hardware, etc. etc.

[...]

Omitting the "<infile" causes this help screen

And how does this work? (Assuming '<' is a special shell
character for redirection, not something that would show up in
'argv' directly.)

I use the following 'dirty' function. Usage:

if (akeyboard(stdin)) help();

/* This is very likely to be non-portable */
/* DOES NOT check fp open for reading */
/* NULL fp is considered a keyboard here! */
static int akeyboard(FILE *fp)
{
#ifndef __TURBOC__
# ifdef __STDC__
/* This dirty operation allows gcc -ansi -pedantic */
extern int fileno(FILE *fp);
extern int isatty(int fn);
# endif
#endif
return ((fp != NULL) && isatty(fileno(fp)));
} /* akeyboard */

There is a corresponding Pascal function for TP in the txtfiles
unit on my page.

 

[Mabden]

In other words, if you do not like 8-character indentation, move
the indentation, not the action of the \t character. Then, before
dumping the bytes to a system that may use something other than
8-character tabs, expand the tabs to blanks.

But that will mess up comments that are lined up like this:
int i; // integer
long l; // long

Try changing your 8-space tabs to my 3-space tabs and you'll see what I
mean.

 

[Gordon Burditt]

In other words, if you do not like 8-character indentation, move

But that will mess up comments that are lined up like this:
int i; // integer
long l; // long

Try changing your 8-space tabs to my 3-space tabs and you'll see what I
mean.

Expanding 8-character tabs to blanks does NOT mean replacing every
tab with 8 blanks.

Gordon L. Burditt

 

[Chris Torek]

But that will mess up comments that are lined up like this:
int i; // integer
long l; // long

Try changing your 8-space tabs to my 3-space tabs and you'll see what I
mean.

I just told you not to change the action of the hardware "horizontal
tab" character. You therefore MUST NOT change 8 to 3. You also
MUST NOT change 3 to 8. Whatever the underlying system has been
doing for tabs, expand the tabs to blanks BEFORE EXPORTING THE CODE
FROM THE UNDERLYING SYSTEM.

(If your hardware tabs expand to every 3rd column, you are using
some seriously bizarre hardware. Really old DEC hardware used
10-column tabs.)

In other words, tabs simply cease to exist *outside* the world that
has them set to "every N'th column", but can exist all you like (or
dislike) *inside* that world, where they are handled consistently.
(Obviously if you have something like a Makefile where the form of
whitespace is significant, you cannot expand out the tabs there.)

When you import text into a system, you can even create (all-new)
tabs, using a program similar to the Unix-y "unexpand" (plain
unexpand does leading tabs only, "unexpand -a" adds embedded tabs).
One must be somewhat careful with this, of course, as it may
affect string literals (but then, so can expanding tabs on the
way out; but that step is required because of inconsistent tab
handling.)

 

[Alan Balmer]

Thanks for the explanation. You probably don't want to look at my code, as
I adhere to the [tab|8_space] indent of K&R.

I don't recall any indent recommendations in K&R, but my copy is
printed on paper (no tab characters) and the indent seems to be four
characters.

 

[Alan Balmer]

Then, for posting to newsgroups, I just run the code through the
"expand" program on Unix-like systems. (I edited Pnews.sh to do
this for me, so that I need not remember to do it manually.)

In other words, if you do not like 8-character indentation, move
the indentation, not the action of the \t character. Then, before
dumping the bytes to a system that may use something other than
8-character tabs, expand the tabs to blanks.

It seems a lot easier just to not use tabs in the first place ;-)