By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,652 Members | 1,460 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,652 IT Pros & Developers. It's quick & easy.

K&R exercises

P: n/a
mdh
Hi Group,
Not looking for an answer, but more of an explanation. Thinking back
to those heady days when you had the time to do them, may I ask this.

Exercise 1-22 asks for a program to "fold" long input lines into 2 or
more shorter lines before the nth column... etc etc. Now, there are
numerous anwers on the web and in the "C answer book", which includes a
function to expand the tabs to blanks ( depending upon where the tab is
in relationship to the next tab-stop). I have been trying to understand
why one would do this....why not just leave the tabs alone.

Not even sure if I should have asked this, but anyway.....
Tks

Apr 12 '06 #1
Share this Question
Share on Google+
25 Replies


P: n/a
On 12 Apr 2006 13:18:44 -0700, "mdh" <md**@comcast.net> wrote:
Not looking for an answer, but more of an explanation.
...
function to expand the tabs to blanks ( depending upon where the tab is
in relationship to the next tab-stop). I have been trying to understand
why one would do this....why not just leave the tabs alone.


<off-topic>
Simple:

(a) Some devices (printers) do not process tabs - They may ignore
them, or print only one space, etc. In a modern computer/OS the
printer driver will perform the tab expansion automatically, but for
other devices you need to do it as a separate step.

(b) I use 4 column tab stops in my code. Some of my colleagues use 3
or 8. (Yes, we should have coding standards for that, but that is a
separate story) Code carefully and beautifully formatted in somebody's
screen, looks terrible when somebody looks at it with different
default settings in his/her editor. Unless you use spaces instead of
tabs.
</off-topic>
Apr 12 '06 #2

P: n/a
mdh

Roberto Waltman wrote:

Simple:


<OT>

thank you Roberto...yes...I realize that the text is a bit old...but it
sure is a thrill to go back to the masters.

Thanks for that explantation.

<OT>

Apr 12 '06 #3

P: n/a
mdh wrote:
Not looking for an answer, but more of an explanation. Thinking back
to those heady days when you had the time to do them, may I ask this.

Exercise 1-22 asks for a program to "fold" long input lines into 2 or
more shorter lines before the nth column... etc etc. Now, there are
numerous anwers on the web and in the "C answer book", which includes a
function to expand the tabs to blanks ( depending upon where the tab is
in relationship to the next tab-stop). I have been trying to understand
why one would do this....why not just leave the tabs alone.


At some point you'll need to convert tabs into spaces in order to
display them. This might be in the firmware of the terminal or printer,
the code of the terminal emulator window, or the display function of the
editor. For example, the following excerpt from the NetBSD kernel
terminal handling code converts tabs into spaces when output is going
into a device that can't handle tabs on its own:

if (c == '\t' &&
ISSET(oflag, OXTABS) && !ISSET(tp->t_lflag, EXTPROC)) {
c = 8 - (tp->t_column & 7);
notout = b_to_q(" ", c, &tp->t_outq);

--
Diomidis Spinellis
Code Quality: The Open Source Perspective (Addison-Wesley 2006)
http://www.spinellis.gr/codequality
Apr 12 '06 #4

P: n/a
mdh wrote:
Now, there are
numerous anwers on the web and in the "C answer book", which includes a
function to expand the tabs to blanks ( depending upon where the tab is
in relationship to the next tab-stop). I have been trying to understand
why one would do this....why not just leave the tabs alone.

Not even sure if I should have asked this, but anyway.....


Suppose I have my tabs set to eight spaces

#include <stdio.h>
int main(void) {
char name[30]; /* user's name */
fgets(name, 30, stdin); /* needs error checking */
printf("Hello, %s!", name); /* greet user */
return 0; /* and exit */
}

and Louise, who prefers three spaced tabs, opens my source file

#include <stdio.h>
int main(void) {
char name[30]; /* user's name */
fgets(name, 30, stdin); /* needs error checking */
printf("Hello, %s!", name); /* greet user */
return 0; /* and exit */
}

So if there's a chance Louise will see my code, I'd rather make her have
some extra work to format the coding to her liking, than to have her see
that mess you see up there :)

--
If you're posting through Google read <http://cfaj.freeshell.org/google>
Apr 12 '06 #5

P: n/a

"mdh" <md**@comcast.net> wrote in message
news:11**********************@z34g2000cwc.googlegr oups.com...
Hi Group,
Not looking for an answer, but more of an explanation. Thinking back
to those heady days when you had the time to do them, may I ask this.

Exercise 1-22 asks for a program to "fold" long input lines into 2 or
more shorter lines before the nth column... etc etc. Now, there are
numerous anwers on the web and in the "C answer book", which includes a
function to expand the tabs to blanks ( depending upon where the tab is
in relationship to the next tab-stop). I have been trying to understand
why one would do this....why not just leave the tabs alone.

Not even sure if I should have asked this, but anyway.....
Tks

Say you are displaying a page on the screen, in a window that can handle
80 columns (of non-proportional font), and are not using a horizontal
scrollbar. Or say you have a screen that can display a maximum of 80
columns, and does not wrap.

If a line has several tabs in it, you have to expand those tabs into the
appropriate number of blanks in order to decide when to "fold" the
line, so that the user can see the text. Otherwise it is off screen.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project

Apr 12 '06 #6

P: n/a
mdh
Thank you to all that replied.

Apr 12 '06 #7

P: n/a
Roberto Waltman wrote:
<snip>
(b) I use 4 column tab stops in my code. Some of my colleagues use 3
or 8. (Yes, we should have coding standards for that, but that is a
separate story) Code carefully and beautifully formatted in somebody's
screen, looks terrible when somebody looks at it with different
default settings in his/her editor. Unless you use spaces instead of
tabs.


Carefully, beautifully and (as I infer) *manually* formatting code is a
tremendous waste of time, and as you've discovered, it's not a stable process.

If you use tabs, use them for logical indentation, not to produce a
particular amount of whitespace, and your formatting problems vanish into
thin air. For all the rest there's pretty printers, or, in these modern
times, IDEs with autoformatting.

This is more on topic in this newsgroup than others, as C programmers have a
long and venerable tradition of formatting code in a myriad different ways,
each superior to the others. One shudders to think at the amount of
productive coding time that must have been wasted by people laying out their
source code to look good on their monitors, only to be tempted to do it all
over again when they change tab sizes, monitors, or personal predilections.

Hm. If this sounds like a flame to you, please ignore it. Formatting issues
rarely spawn productive discussions, but I had to get it out of my system.

S.
Apr 12 '06 #8

P: n/a
Pedro Graca forgot the '\n' on the printf() call:
#include <stdio.h>
int main(void) {
char name[30]; /* user's name */
fgets(name, 30, stdin); /* needs error checking */
#if 0 printf("Hello, %s!", name); /* greet user */ #endif
printf("Hello, %s!\n", name); /* greet user */
return 0; /* and exit */
}


--
If you're posting through Google read <http://cfaj.freeshell.org/google>
Apr 12 '06 #9

P: n/a
"mdh" <md**@comcast.net> writes:
Thank you to all that replied.


For what? Replied to what?

Read <http://cfaj.freeshell.org/google/>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 13 '06 #10

P: n/a
Pedro Graca <he****@dodgeit.com> writes:
mdh wrote:
Now, there are
numerous anwers on the web and in the "C answer book", which includes a
function to expand the tabs to blanks ( depending upon where the tab is
in relationship to the next tab-stop). I have been trying to understand
why one would do this....why not just leave the tabs alone.

Not even sure if I should have asked this, but anyway.....


Suppose I have my tabs set to eight spaces

#include <stdio.h>
int main(void) {
char name[30]; /* user's name */
fgets(name, 30, stdin); /* needs error checking */
printf("Hello, %s!", name); /* greet user */
return 0; /* and exit */
}

and Louise, who prefers three spaced tabs, opens my source file

#include <stdio.h>
int main(void) {
char name[30]; /* user's name */
fgets(name, 30, stdin); /* needs error checking */
printf("Hello, %s!", name); /* greet user */
return 0; /* and exit */
}

So if there's a chance Louise will see my code, I'd rather make her have
some extra work to format the coding to her liking, than to have her see
that mess you see up there :)


I *never* set tabstops to anything other than 8 (so things look
correct when printed or viewed with any text viewing program), but I
usually use 4-column indentation. My editor (vi) automatically uses a
combination of tabs and spaces for indentation. (And then I usually
expand tabs to spaces myself.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 13 '06 #11

P: n/a
On 12 Apr 2006 13:18:44 -0700, "mdh" <md**@comcast.net> wrote:
Hi Group,
Not looking for an answer, but more of an explanation. Thinking back
to those heady days when you had the time to do them, may I ask this.

Exercise 1-22 asks for a program to "fold" long input lines into 2 or
more shorter lines before the nth column... etc etc. Now, there are
numerous anwers on the web and in the "C answer book", which includes a
function to expand the tabs to blanks ( depending upon where the tab is
in relationship to the next tab-stop). I have been trying to understand
why one would do this....why not just leave the tabs alone.

Not even sure if I should have asked this, but anyway.....
Tks

[OT]
I had to do this preprocessing of tab stops-to-spaces for some ASCII
files that were being FTP'ed to another system in ASCII mode of some
C source files. The tab stops were set in the editor to every 4
columns but either the FTP client or the server (not sure which now,
was a long time ago) expanded tab stops itself, and to every 8
columns, making a mess of the sources.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Apr 13 '06 #12

P: n/a
ozbear wrote:
The tab stops were set in the editor to every 4
columns but either the FTP client or the server (not sure which now,
was a long time ago) expanded tab stops itself, and to every 8
columns, making a mess of the sources.


Because of this and other similar annoyances, a former employer coding
standard specifically prohibited the use of tabs for indentation, a
practice I have adopted.

Even if everybody is using the same indentation and tab stop settings,
if you have, for example, 4 col indentation and 8 col hard tab stops,
like in Keith's post, things like adding a line number at the start of
every line before printing, (common practice for code reviews,) may
break havoc with the formatting.

Apr 13 '06 #13

P: n/a
Skarmander wrote:
Roberto Waltman wrote:
Code carefully and beautifully formatted in somebody's
screen, looks terrible when somebody looks at it with different
default settings in his/her editor. Unless you use spaces instead of
tabs.
Carefully, beautifully and (as I infer) *manually* formatting code is a
tremendous waste of time, and as you've discovered, it's not a stable process.

If you use tabs, use them for logical indentation, not to produce a
particular amount of whitespace, and your formatting problems vanish into
thin air. For all the rest there's pretty printers, or, in these modern
times, IDEs with autoformatting.


I typed that "keyboard in cheek." Of course I use "tabs" for logical
indentation, (as in, press the tab key at the beginning of that line,
indent that line; select a group of lines or a C block, press tab,
indent the whole block; press shift-tab or whatever, un-indent the
whole block etc.) But after configuring my editor, I trust it to never
insert an actual tab character in the file. Otherwise the formatting
problems do not "vanish into thin air", because the presence of tabs
is what created them in the first place. (And yes, I use programs as
astyle and indent, or whatever the IDE du jour will provide)
This is more on topic in this newsgroup than others, as C programmers have a
long and venerable tradition of formatting code in a myriad different ways,
each superior to the others. One shudders to think at the amount of
productive coding time that must have been wasted by people laying out their
source code to look good on their monitors, only to be tempted to do it all
over again when they change tab sizes, monitors, or personal predilections.
I agree. I am fighting this at work now. In one of the projects I am
working now, I adopted the style of one of my colleagues to make sure
she will not waste time reformatting my code to her liking when she
has to use it.
Hm. If this sounds like a flame to you, please ignore it. Formatting issues
rarely spawn productive discussions, but I had to get it out of my system.


Nope. I strongly believe that adherence to coding standards (covering
much more than indentation style) does indeed help to produce better
quality software. For any project involving more than one programmer,
it makes much easier to understand, integrate, reuse, test, etc. each
others code.

Tell it to one of my colleagues, that likes to declare macros that
expand to function declarators + the initial brace of a function body.
[ /* this is a complete function */ MACRO statement; statement; ... }
] This makes the code more difficult to read in addition to breaking
the functionality of pretty-printers and editors that allow you to
jump to the beginning of a block, or function, etc.

Or to another, that always puts a return statement at the end of void
functions, and adds this line to the end of every file:
/**************** end of file *********************/
(I guess I should be grateful, that stops me from going on editing
vacuum...)

Or to another, that the only comments that he ever uses are like this:
/* these lines changed by ???? */
/* end of changed lines */
Information I can easily get from CVS, and totally useless to
understand the reasons for the code changes.

I guess I had to get this out of my system too ...
Apr 13 '06 #14

P: n/a
Roberto Waltman wrote:
Skarmander wrote:
Roberto Waltman wrote:
Code carefully and beautifully formatted in somebody's
screen, looks terrible when somebody looks at it with different
default settings in his/her editor. Unless you use spaces instead of
tabs. Carefully, beautifully and (as I infer) *manually* formatting code is a
tremendous waste of time, and as you've discovered, it's not a stable process.

If you use tabs, use them for logical indentation, not to produce a
particular amount of whitespace, and your formatting problems vanish into
thin air. For all the rest there's pretty printers, or, in these modern
times, IDEs with autoformatting.


I typed that "keyboard in cheek." Of course I use "tabs" for logical
indentation, (as in, press the tab key at the beginning of that line,
indent that line; select a group of lines or a C block, press tab,
indent the whole block; press shift-tab or whatever, un-indent the
whole block etc.) But after configuring my editor, I trust it to never
insert an actual tab character in the file. Otherwise the formatting
problems do not "vanish into thin air", because the presence of tabs
is what created them in the first place. (And yes, I use programs as
astyle and indent, or whatever the IDE du jour will provide)

Actually, I do use tabs, and I never run into trouble, as long as people who
think indentation is for lining up things do not pass by and hack my source
(you see the fatal flaw in this approach). That is, I use *one* tab to
indent blocks *and nothing else*. If this style is followed the source will
look "correct" regardless of the tab settings (well, as long as a tab is not
invisible, obviously). Whether you like to see 2, 3, 4 or 8 spaces, or even
tab stops, doesn't matter.

The great evil is using *both* tabs and spaces, which does not work, ever
(one of Python's great sources of trouble is not its semantic white space,
but the fact that it allows both tabs and spaces in a misplaced gesture of
tolerance). People usually eschew tabs because "tabs for logical indent
only" idea is rarely strictly adhered to, so the mixing of tabs and spaces
becomes inevitable, and everybody loses.

With regret I've recently configured my editor to replace tabs with spaces
on saving, since I've pretty much lost the battle against the space-tweaking
hordes -- although I do not like losing the "one tab = one indent level"
idea (which allows for easy formatting to just about anything).

<snip> Tell it to one of my colleagues, that likes to declare macros that
expand to function declarators + the initial brace of a function body.
[ /* this is a complete function */ MACRO statement; statement; ... }
] This makes the code more difficult to read in addition to breaking
the functionality of pretty-printers and editors that allow you to
jump to the beginning of a block, or function, etc.
Now that is pretty bletcherous. I'm glad I've never had to work with someone
capable of ignoring boundaries so casually. :-)
Or to another, that always puts a return statement at the end of void
functions, and adds this line to the end of every file:
/**************** end of file *********************/
(I guess I should be grateful, that stops me from going on editing
vacuum...)
All those stars remind me of those info boxes people sometimes put at the
beginning of the file -- you know the ones, that tell you the name of the
file, the company, the authors, the last modification date, the phase of the
moon and last but not least the (always incomplete) version history, as a
poor man's version control. Great care is usually taken to make those star
boxes look nice, although that never stops them from getting out of date.
Or to another, that the only comments that he ever uses are like this:
/* these lines changed by ???? */
/* end of changed lines */
Information I can easily get from CVS, and totally useless to
understand the reasons for the code changes.

As per above, be glad you *have* CVS. The programmer in question may have
gotten used to environments where no versioning system was available. These
harsh conditions often lead to improvised tools for survival...

S.
Apr 13 '06 #15

P: n/a
On Thu, 13 Apr 2006 19:23:04 +0200, Skarmander
<in*****@dontmailme.com> wrote:
Roberto Waltman wrote:
Skarmander wrote:
Roberto Waltman wrote:
Code carefully and beautifully formatted in somebody's
screen, looks terrible when somebody looks at it with different
default settings in his/her editor. Unless you use spaces instead of
tabs.
Carefully, beautifully and (as I infer) *manually* formatting code is a
tremendous waste of time, and as you've discovered, it's not a stable process.

If you use tabs, use them for logical indentation, not to produce a
particular amount of whitespace, and your formatting problems vanish into
thin air. For all the rest there's pretty printers, or, in these modern
times, IDEs with autoformatting.
I typed that "keyboard in cheek." Of course I use "tabs" for logical
indentation, (as in, press the tab key at the beginning of that line,
indent that line; select a group of lines or a C block, press tab,
indent the whole block; press shift-tab or whatever, un-indent the
whole block etc.) But after configuring my editor, I trust it to never
insert an actual tab character in the file. Otherwise the formatting
problems do not "vanish into thin air", because the presence of tabs
is what created them in the first place. (And yes, I use programs as
astyle and indent, or whatever the IDE du jour will provide)

Actually, I do use tabs, and I never run into trouble, as long as people who
think indentation is for lining up things


Ah, this *is* comp.lang.c, not comp.lang.python ;-)
do not pass by and hack my source
Precisely the problem. If no-one but yourself ever uses your source,
who cares what you use?
(you see the fatal flaw in this approach). That is, I use *one* tab to
indent blocks *and nothing else*. If this style is followed the source will
look "correct" regardless of the tab settings (well, as long as a tab is not
invisible, obviously). Whether you like to see 2, 3, 4 or 8 spaces, or even
tab stops, doesn't matter.

The great evil is using *both* tabs and spaces, which does not work, ever
(one of Python's great sources of trouble is not its semantic white space,
but the fact that it allows both tabs and spaces in a misplaced gesture of
tolerance). People usually eschew tabs because "tabs for logical indent
only" idea is rarely strictly adhered to, so the mixing of tabs and spaces
becomes inevitable, and everybody loses.

With regret I've recently configured my editor to replace tabs with spaces
on saving, since I've pretty much lost the battle against the space-tweaking
hordes -- although I do not like losing the "one tab = one indent level"
idea (which allows for easy formatting to just about anything).
Why? A good editor will allow you to use the tab key (and shift-tab)
just as you have been, while actually inserting spaces.
<snip>
Tell it to one of my colleagues, that likes to declare macros that
expand to function declarators + the initial brace of a function body.
[ /* this is a complete function */ MACRO statement; statement; ... }
] This makes the code more difficult to read in addition to breaking
the functionality of pretty-printers and editors that allow you to
jump to the beginning of a block, or function, etc.

Now that is pretty bletcherous. I'm glad I've never had to work with someone
capable of ignoring boundaries so casually. :-)
Or to another, that always puts a return statement at the end of void
functions, and adds this line to the end of every file:
/**************** end of file *********************/
(I guess I should be grateful, that stops me from going on editing
vacuum...)

All those stars remind me of those info boxes people sometimes put at the
beginning of the file -- you know the ones, that tell you the name of the
file, the company, the authors, the last modification date, the phase of the
moon and last but not least the (always incomplete) version history, as a
poor man's version control. Great care is usually taken to make those star
boxes look nice, although that never stops them from getting out of date.
Or to another, that the only comments that he ever uses are like this:
/* these lines changed by ???? */
/* end of changed lines */
Information I can easily get from CVS, and totally useless to
understand the reasons for the code changes.
I maintain a large amount of legacy code. These comment blocks are the
first thing to go when I work on a program. They're misleading and
interrupt the flow of the real code. I've seen some that went on for
pages, and caused a great deal of trouble for colleagues using editors
which don't display comments differently (I have mine set to
color-code them in green.) It's frustrating to spend time fixing a bug
in code that doesn't actually get compiled <g>.

As per above, be glad you *have* CVS. The programmer in question may have
gotten used to environments where no versioning system was available. These
harsh conditions often lead to improvised tools for survival...


--
Al Balmer
Sun City, AZ
Apr 13 '06 #16

P: n/a
Roberto Waltman <us****@rwaltman.net> writes:
ozbear wrote:
The tab stops were set in the editor to every 4
columns but either the FTP client or the server (not sure which now,
was a long time ago) expanded tab stops itself, and to every 8
columns, making a mess of the sources.


Because of this and other similar annoyances, a former employer coding
standard specifically prohibited the use of tabs for indentation, a
practice I have adopted.

Even if everybody is using the same indentation and tab stop settings,
if you have, for example, 4 col indentation and 8 col hard tab stops,
like in Keith's post, things like adding a line number at the start of
every line before printing, (common practice for code reviews,) may
break havoc with the formatting.


Agreed. In the past, I've used line-numbering programs that insert
exactly 8 columns at the beginning of each line, so 8-column tab stops
won't be affected. But I find it easier to avoid tabs altogether.
For one thing, tabs often show up inconsistently; one line might start
with a tab, and the next might start with 8 spaces, and this can
change arbitrarily as the file is edited. This makes file comparisons
(diff) more difficult, and wastes space in revision control systems
such as CVS.

<OT>The version of vi I use insists on using tabs for indentation
whenever it can, but I have a two-keystroke macro that filters the
current editor buffer through "expand", and I've developed the habit
of invoking it before saving the file.</OT>

<EVEN_MORE_OT>Unfortunately, tabs are (nearly) required in
Makefiles.</EVEN_MORE_OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 13 '06 #17

P: n/a
On 2006-04-13, Skarmander <in*****@dontmailme.com> wrote:
The great evil is using *both* tabs and spaces, which does not work,
ever (one of Python's great sources of trouble is not its semantic
white space, but the fact that it allows both tabs and spaces in a
misplaced gesture of tolerance). People usually eschew tabs because
"tabs for logical indent only" idea is rarely strictly adhered to, so
the mixing of tabs and spaces becomes inevitable, and everybody loses.


There is a quite common convention for mixing tabs and spaces in C
source files which is to assume a tabstop of 8, and to use tab
characters for every sequence of 8 columns' worth of whitespace at the
start of lines. i.e. as if you'd done everything with spaces and then
s/^ {8}/\t/g on every line. So if you use an indent level of 4 columns,
you'd get four spaces for one level of indent, and then a tab for two
levels.
Apr 13 '06 #18

P: n/a
Ben C <sp******@spam.eggs> writes:
On 2006-04-13, Skarmander <in*****@dontmailme.com> wrote:
The great evil is using *both* tabs and spaces, which does not work,
ever (one of Python's great sources of trouble is not its semantic
white space, but the fact that it allows both tabs and spaces in a
misplaced gesture of tolerance). People usually eschew tabs because
"tabs for logical indent only" idea is rarely strictly adhered to, so
the mixing of tabs and spaces becomes inevitable, and everybody loses.


There is a quite common convention for mixing tabs and spaces in C
source files which is to assume a tabstop of 8, and to use tab
characters for every sequence of 8 columns' worth of whitespace at the
start of lines. i.e. as if you'd done everything with spaces and then
s/^ {8}/\t/g on every line. So if you use an indent level of 4 columns,
you'd get four spaces for one level of indent, and then a tab for two
levels.


Which is what vi does by default; it has separate settings for tabstop
size and indentation level. If you think that's a bad idea, I won't
argue with you, but you will need to deal with code that was created
in vi.

Many problems can be avoided by consistently using 8-column tabstops.
Even more problems can be avoided by not using tabs at all.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 13 '06 #19

P: n/a

Pedro Graca wrote:
mdh wrote:
Now, there are
numerous anwers on the web and in the "C answer book", which includes a
function to expand the tabs to blanks ( depending upon where the tab is
in relationship to the next tab-stop). I have been trying to understand
why one would do this....why not just leave the tabs alone.

Not even sure if I should have asked this, but anyway.....


Suppose I have my tabs set to eight spaces

#include <stdio.h>
int main(void) {
char name[30]; /* user's name */
fgets(name, 30, stdin); /* needs error checking */
printf("Hello, %s!", name); /* greet user */
return 0; /* and exit */
}

and Louise, who prefers three spaced tabs, opens my source file

#include <stdio.h>
int main(void) {
char name[30]; /* user's name */
fgets(name, 30, stdin); /* needs error checking */
printf("Hello, %s!", name); /* greet user */
return 0; /* and exit */
}

So if there's a chance Louise will see my code, I'd rather make her have
some extra work to format the coding to her liking, than to have her see
that mess you see up there :)


That mess can be avoided if you follow the convention of using tabs
only for white space at the beginning of the line, and spaces for other
white space.

I used to follow that convention, but I've changed to using only
spaces for the following 2 reasons:
1) I thought that people who preferred indentation other than 4
spaces (which is what I like) would simply change the tapstop
setting in their editor, but I discovered that many people don't even
learn their editor well enough to know how to do that. I don't
understand how these people function, but they exist, and
are more prevalent that you might think.
2) If you expect people to modify their tabstop to change the
indentation level, you still have to assume an 8 space indentation
in terms of keeping your line-lengths under 78...so there's just no
point. Use spaces and indent as you like...just make sure your
indentation spacing is a power of 2. (ie, don't indent with
3 spaces....it's just wrong!)

Apr 13 '06 #20

P: n/a
Keith Thompson wrote:
Ben C <sp******@spam.eggs> writes:
On 2006-04-13, Skarmander <in*****@dontmailme.com> wrote:
The great evil is using *both* tabs and spaces, which does not work,
ever (one of Python's great sources of trouble is not its semantic
white space, but the fact that it allows both tabs and spaces in a
misplaced gesture of tolerance). People usually eschew tabs because
"tabs for logical indent only" idea is rarely strictly adhered to, so
the mixing of tabs and spaces becomes inevitable, and everybody loses. There is a quite common convention for mixing tabs and spaces in C
source files which is to assume a tabstop of 8, and to use tab
characters for every sequence of 8 columns' worth of whitespace at the
start of lines. i.e. as if you'd done everything with spaces and then
s/^ {8}/\t/g on every line. So if you use an indent level of 4 columns,
you'd get four spaces for one level of indent, and then a tab for two
levels.


Which is what vi does by default; it has separate settings for tabstop
size and indentation level. If you think that's a bad idea, I won't
argue with you, but you will need to deal with code that was created
in vi.

Aha! I have avoided vi like the plague ever since I encountered it, which is
why I'm ignorant of this. This would explain the most common reason for how
tabs and spaces get mixed up (and yes, the ubiquity of vi means you have to
"deal with it").

I wouldn't say it's a "bad idea" on its own. It just doesn't mesh with other
approaches; none of the approaches that mix tabs and spaces do. It's the
most fragile way to do it, really. I can understand why people who are used
to this model would be reluctant to ever use tabs.
Many problems can be avoided by consistently using 8-column tabstops.
Even more problems can be avoided by not using tabs at all.

In the vi model (or classic typewriter model, if you prefer), the latter
looks like the sanest approach to me. Your formatting has no chance of
surviving any change in settings otherwise.

S.
Apr 14 '06 #21

P: n/a
Skarmander <in*****@dontmailme.com> writes:
Keith Thompson wrote:

[snip]
Which is what vi does by default; it has separate settings for
tabstop
size and indentation level. If you think that's a bad idea, I won't
argue with you, but you will need to deal with code that was created
in vi.

Aha! I have avoided vi like the plague ever since I encountered it,
which is why I'm ignorant of this. This would explain the most common
reason for how tabs and spaces get mixed up (and yes, the ubiquity of
vi means you have to "deal with it").

I wouldn't say it's a "bad idea" on its own. It just doesn't mesh with
other approaches; none of the approaches that mix tabs and spaces
do. It's the most fragile way to do it, really. I can understand why
people who are used to this model would be reluctant to ever use tabs.
Many problems can be avoided by consistently using 8-column tabstops.
Even more problems can be avoided by not using tabs at all.

In the vi model (or classic typewriter model, if you prefer), the
latter looks like the sanest approach to me. Your formatting has no
chance of surviving any change in settings otherwise.


You seem to be implying that, if it weren't for vi's behavior, it
would make sense to use just tabs for indentation, and modify your
editor's tabstop settings so the code looks the way you want it to.
(Even if you're not implying that yourself, others have.)

But if your code assumes 4-column tabstops, wouldn't you have to
specify 4-column tabstops for *everything* you do with the file? In
vi, I can do ":set tabstop=4", but what if I want to view the file
with "less" or "more"? What if I want to print it, or run it through
a text-to-PostScript converter? What if it's only a few lines long,
and I just want to "cat" it? What if I want to let someone else view
or edit the file in his own environment? (Some of these examples are
Unix-specific, but I'm sure there are corresponding tools on other
systems.)

In my own work, I've usually used tools that allow me to specify
tabstops, but I've never felt the need to set them to anything other
than 8, and I'm having trouble understanding how you can deal with C
source code without a consistent tabstop setting.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 14 '06 #22

P: n/a
Keith Thompson wrote:
Skarmander <in*****@dontmailme.com> writes:
Keith Thompson wrote: [snip]
Which is what vi does by default; it has separate settings for
tabstop
size and indentation level. If you think that's a bad idea, I won't
argue with you, but you will need to deal with code that was created
in vi.

Aha! I have avoided vi like the plague ever since I encountered it,
which is why I'm ignorant of this. This would explain the most common
reason for how tabs and spaces get mixed up (and yes, the ubiquity of
vi means you have to "deal with it").

I wouldn't say it's a "bad idea" on its own. It just doesn't mesh with
other approaches; none of the approaches that mix tabs and spaces
do. It's the most fragile way to do it, really. I can understand why
people who are used to this model would be reluctant to ever use tabs.
Many problems can be avoided by consistently using 8-column tabstops.
Even more problems can be avoided by not using tabs at all.

In the vi model (or classic typewriter model, if you prefer), the
latter looks like the sanest approach to me. Your formatting has no
chance of surviving any change in settings otherwise.


You seem to be implying that, if it weren't for vi's behavior, it
would make sense to use just tabs for indentation, and modify your
editor's tabstop settings so the code looks the way you want it to.
(Even if you're not implying that yourself, others have.)

This is basically what I'm saying, but with a caveat. See below.
But if your code assumes 4-column tabstops, wouldn't you have to
specify 4-column tabstops for *everything* you do with the file?
Here's the thing. My code *does not* assume 4-column tabstops. It assumes
that tabstops do not coincide, and *nothing more*. Or to put it another way:
I basically do not format my code except for inserting newlines at
appropriate points. Where I place my tabs is not a creative decision, it's
practically part of the syntax.

You may be thinking of code that tries to do fancy lining up of items,
whether with tabs or spaces or both. Here's a typical excerpt from a Win32
program, which particularly suffers from the "functions with argument lists
as long as your arm" problem (as well as many others we'll ignore here):

CONTEXT Context;
DWORD dwThreadId,dwNumBytesXferred;
HANDLE hThread;
HINSTANCE hinstKrnl = GetModuleHandle(__TEXT("Kernel32"));
MEMORY_BASIC_INFORMATION mbi;

hThread = CreateRemoteThread(hProcess,NULL,dwNumBytes +
sizeof(HANDLE),(LPTHREAD_START_ROUTINE)
GetProcAddress(hinstKrnl,"ExitThread"),
0,CREATE_SUSPENDED,&dwThreadId);

Your newsreader may reformat the above and prevent my point from coming
across (in a way), but in the above code tabs are used to line up the
declarations and the function call arguments. The declarations only line up
neatly if you use 8-column tab stops, however. If lining things up neatly is
a priority to you, you'd need to reformat the code when you change tab
columns or simply replace them with spaces and be done with it.

Here's how I would format that code:

CONTEXT context;
DWORD dwThreadId, dwNumBytesXferred;
HANDLE hThread;
HINSTANCE hInstKrnl = GetModuleHandle(__TEXT("Kernel32"));
MEMORY_BASIC_INFORMATION mbi;

hThread = CreateRemoteThread(
hProcess, NULL, dwNumBytes + sizeof(HANDLE),
(LPTHREAD_START_ROUTINE) GetProcAddress(hinstKrnl, "ExitThread"),
0, CREATE_SUSPENDED, &dwThreadId
);

This code will look fine regardless of your tabstop settings, unless lines
start to wrap. This in itself may be considered an argument against, or an
argument for letting word wrapping take care of itself and not break up long
lines artificially based on your screen size -- but most tools simply aren't
clever enough to word-wrap code in a pleasing manner, or even at all.

Note that only single spaces are used, to separate tokens. I'm also well
aware that using brace-style indentation for function argument lists is
unusual, but it works well for me (and yes, I use K&R bracing).
In vi, I can do ":set tabstop=4", but what if I want to view the file
with "less" or "more"? What if I want to print it, or run it through a
text-to-PostScript converter? What if it's only a few lines long, and I
just want to "cat" it? What if I want to let someone else view or edit
the file in his own environment? (Some of these examples are
Unix-specific, but I'm sure there are corresponding tools on other
systems.)
Well, in all those examples, the way the code looks (or rather the
indentation) would change if tabstops are different, but the key point in
this is that if you do this you're not supposed to care, no more than about
how your newsreader wraps this paragraph. The whole idea behind using tabs
as logical indentation is that a tab only means "one level of indentation
deeper".
In my own work, I've usually used tools that allow me to specify
tabstops, but I've never felt the need to set them to anything other
than 8, and I'm having trouble understanding how you can deal with C
source code without a consistent tabstop setting.


I cannot deal with *other* people's source code if tabs are used in the
manner I initially described, no. If tabs and spaces are combined in some
way to produce code that neatly lines up, then you have to communicate your
tab stops to the other side or things will break. Hence, if you do this, you
are practically morally obliged to not use any tabs and replace them with
spaces on saving.

S.
Apr 14 '06 #23

P: n/a
Bill Pursell wrote:
.... snip ... 2) If you expect people to modify their tabstop to change the
indentation level, you still have to assume an 8 space indentation
in terms of keeping your line-lengths under 78...so there's just no
point. Use spaces and indent as you like...just make sure your
indentation spacing is a power of 2. (ie, don't indent with
3 spaces....it's just wrong!)


Er - I habitually use 3 for the indent level, and I have yet had
any compiler, lint, etc. complain about it. I also eschew tabs,
except in makefiles.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Apr 14 '06 #24

P: n/a
CBFalconer wrote:
Bill Pursell wrote:
... snip ...
2) If you expect people to modify their tabstop to change the
indentation level, you still have to assume an 8 space indentation
in terms of keeping your line-lengths under 78...so there's just no
point. Use spaces and indent as you like...just make sure your
indentation spacing is a power of 2. (ie, don't indent with
3 spaces....it's just wrong!)


Er - I habitually use 3 for the indent level, and I have yet had
any compiler, lint, etc. complain about it. I also eschew tabs,
except in makefiles.

I use three spaces too. In gnu make, if tab is too much trouble, you can
separate the rule from the command with semi-colon.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Apr 14 '06 #25

P: n/a
On Fri, 14 Apr 2006 09:24:23 -0400, in comp.lang.c , Joe Wright
<jo********@comcast.net> wrote:
CBFalconer wrote:
Bill Pursell wrote:
... snip ...
2) If you expect people to modify their tabstop to change the
indentation level, you still have to assume an 8 space indentation
in terms of keeping your line-lengths under 78...so there's just no
point. Use spaces and indent as you like...just make sure your
indentation spacing is a power of 2. (ie, don't indent with
3 spaces....it's just wrong!)


Er - I habitually use 3 for the indent level, and I have yet had
any compiler, lint, etc. complain about it. I also eschew tabs,
except in makefiles.

I use three spaces too. In gnu make, if tab is too much trouble, you can
separate the rule from the command with semi-colon.


people who use three spaces are one of my pet hates :-)
Comes from learning fortran first I suspect, but odd numbers just feel
wrong anyway...
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Apr 14 '06 #26

This discussion thread is closed

Replies have been disabled for this discussion.