R
Richard
Victor Bazarov said:
By tab length I meant the space taken for each indent. In
Linux it is 8 spaces. It's fairly common to refer to the indent length
as the tab length. Apologies for any confusion.
By tab length I meant the space taken for each indent. In
Linux it is 8 spaces. It's fairly common to refer to the indent length
as the tab length. Apologies for any confusion.
J
James Kanze
So called style issues certainly vary in importance, from simple
personal taste (indent 3 spaces or 4) to something that is
absolute (no indentation what so ever, or---and I've actually
seen it done---random indentation). I understand your point
concerning the braces; leaving them out does allow one
additional error possibility when modifying code. In practice,
however, *IF* a reasonable style is rigorously adhered to,
missing braces when needed will stick out, and so won't occur.
The importance, here, is that the code is formatting using one,
reasonable style, and that that style does make the braces (or
the absence thereof) stick out.
So don't indent like that. My editor almost won't let me; I
have to do a lot of extra work to get it like that.
I don't know. There's still an indentation error on doY(), and
I'm not sure I'd spot the fact that doY() isn't part of the if
immediately.
I might add that while not an absolute rule, like "use
indentation", I'd tend to reject styles which have code
following an open brace or before a closing brace, on the same
line. My rule is more or less that either:
-- the opening brace is on a line by itself, so you can't miss
it, or
-- you always use braces, so you don't have to see it to know
that it's there,
and
-- the closing brace is on a line by itself, or
-- it is always the first non white space, and anything which
follows is part of the "enclosing" statement (else of an
if/else, or while of a do/while).
I currently use the second of each of these rules, but I'd have
no trouble using the first if that's what my co-workers
preferred (and IMHO, omitting the braces is only acceptable if
you use the first).
I might add that regardless of which of the above rules I use,
the opening brace of a function or a class is always on a line
by itself. (Just like in K&R
.)
J
James Kanze
The "standard" is (and always has been) eight. (Don't ask me
why, or who decided, but it goes back long before Unix.) Of
course, most editors will give you any number of options, but
they don't help when outputting the code using other tools; if
your source code has tab characters in it, then you must expand
them to 8, or others will not see the code as you do.
Eight is, of course, a pretty poor choice for indentation. Far
too big. So you don't use tabs for indentation, but spaces (or
a mixture of tabs and spaces). Off hand, for indentation, 2 or
less is too little, and 6 or more too much. As computer
scientists, of course, we favor powers of 2, and the only power
of 2 in the acceptable range is 4, so that's what we use
.(But I've maintained code where the original coder used three,
and there was no problem with it. I suspect that five would
also be just as good.)
A
Alf P. Steinbach
* James Kanze:
Ah, well, it has shifted a bit, like, continents drifting.
When I worked in Andersen Consulting (now Accenture), Norway, we had a
big motivational meeting where it was asked, how many spaces per tab?
Just for the hell of it I answered loud and clear: "three, of course".
And so that was decided... Just like that. I even managed to get away
with Petzold-style braces -- simply by referring to Petzold -- like
void foo()
{
int x = 666;
if( 3 == x )
{
cout << "Hola hola!" << endl;
}
}
Note the extreme beauty of this. <g>
8 spaces per tab was so common once that it's part of the Windows
command interpreter and the Windows standard editor Notepad, but
Microsoft set a precedent for 4 spaces per tab in Windows programming,
and so nearly all Windows programming editors have that as default. Or
at least, nearly all reasonable Windows programming editors. If it has
8 spaces per tab as default, then it just isn't reasonable, because then
it can't handle Microsoft code without special configuration.
So, we have three main conventions:
Unix: 8
Firms that have adopted Alf's frivolous suggestion: 3
Windows: 4
Of course, I'm sure that some folks will want to post here claiming that
I'm /stealing credit/ for the brilliant 3-spaces-per-tab idea. Hah! I
have a US patent on that...
Ah, well, it has shifted a bit, like, continents drifting.
When I worked in Andersen Consulting (now Accenture), Norway, we had a
big motivational meeting where it was asked, how many spaces per tab?
Just for the hell of it I answered loud and clear: "three, of course".
And so that was decided... Just like that. I even managed to get away
with Petzold-style braces -- simply by referring to Petzold -- like
void foo()
{
int x = 666;
if( 3 == x )
{
cout << "Hola hola!" << endl;
}
}
Note the extreme beauty of this. <g>
8 spaces per tab was so common once that it's part of the Windows
command interpreter and the Windows standard editor Notepad, but
Microsoft set a precedent for 4 spaces per tab in Windows programming,
and so nearly all Windows programming editors have that as default. Or
at least, nearly all reasonable Windows programming editors. If it has
8 spaces per tab as default, then it just isn't reasonable, because then
it can't handle Microsoft code without special configuration.
So, we have three main conventions:
Unix: 8
Firms that have adopted Alf's frivolous suggestion: 3
Windows: 4
Of course, I'm sure that some folks will want to post here claiming that
I'm /stealing credit/ for the brilliant 3-spaces-per-tab idea. Hah! I
have a US patent on that...
W
werasm
Richard wrote:
This is not my bracketing style, but a style I used to prove a point.
My real style would be:
if( condition )
{
doX();
}
doY();
The point is: Presence of brackets (in any style) make error less
probable.
Personally, I don't mind most ways of bracket usage, as long as it is
present
and consistent.
W
This is not my bracketing style, but a style I used to prove a point.
My real style would be:
if( condition )
{
doX();
}
doY();
The point is: Presence of brackets (in any style) make error less
probable.
Personally, I don't mind most ways of bracket usage, as long as it is
present
and consistent.
W
W
werasm
werasm wrote:
Pardon,
Actually...
if( condition )
{
doX();
}
doY();
.... incase I get more comments wrt. synax/style.
Pardon,
Actually...
if( condition )
{
doX();
}
doY();
.... incase I get more comments wrt. synax/style.
J
joe
And here I always thought it was 8 because the one true terminal for
unix was the adm3a and it used 8 characters for the tab stop. I
actually suspect, but can't prove, that eight characters per tabstop
was chosen for ttys because many of the languages used on punch cards
(such as fortran) started at the eighth character and reserved the
first 7 spaces for line numbers and comment characters.
For what it's worth, I tend to like 4 for tabs. That is probably
because I am both a programmer and old school. That is, I both like
that it is a power of 2 and I like that every two tabs matches up with
a "real" tab.
joe
V
Victor Bazarov
joe said:
It's plausible. Fortran IV has the first and the sixth character
special. So, a "regular" statement starts with the seventh, and it
is conceivable that somebody decided to give it a separate buffer
of two characters, although in those days it wasn't commonly done
(wasting bytes like that, I mean).
V
A
arnuld
i have also noticed this but i do not use it myself and have not found
the reason why programmers use this.
BTW, i have learnt 2 coding style from this group:
if ( condition )
rather than
if(condition)
&
if ( condition )
{
//...
}
rather than
if ( condition ) {
// ....
}
i have found them more readable and i never thought so earlier about
that. i will stick with them from now on and as K&R2 says: "pick a
style that suits you, then use it consistently" [page - 10]
B
BobR
arnuld said:
I developed my style with influence from B. Eckel, and the style I used in
Assembler since the early '80s.
void MyFunc1(){
// ... stuff ....
return;
} // last brace indented
void MyFunc2(){
// ... stuff ....
if( blah ) callFireDept();
// or:
// if( blah )
// callFireDept(); // long comment here
if( blah2 ){
callPoliceDept();
}
return;
} // last brace indented
Compact, but still able to see where one thing ends and another begins.
In certain situations, I bend my own rules (like really long lines,
indentation gets out of hand, etc.).
[ but, you gotta do it the way the *boss* says! <G> ]
To each his/her own, use what helps *you*.
Newbies: Just DO NOT put *everything* against the left margin!! PLEASE.
J
Jim Langston
[Totally changing topic, but...]
You put a blank line before the closing brace. I've noticed
this a lot recently (in the past year or two?), but had never
seen it (or at least noticed it) before, and I don't do it
myself.
I'm curious as to why? Is it an intentional decision, or is it
based on some tool, or what?
Agreed. Like you, I've used different styles over time. The
important thing is that the code has an "expected" look; if you
change something, and that look isn't there, it strikes you
immediately. If the rule is "a flow control statement is
followed either by a single indented statement, or a { on a line
by itself, not indented", then adding a second statement just
doesn't look right unless you add the {.
============
It is strange, but in the message I posted, there was NOT an extra space
before the closing bracket. But you quote me with the space. I don't know
if it was your reader or not, but I look at my post and the extra space is
not there.
That is:
if ( condition )
{
statements
}
should be 4 lines. The if, left bracket, statements, right bracket. If you
see an extra line before the end bracket somethings amiss.
You put a blank line before the closing brace. I've noticed
this a lot recently (in the past year or two?), but had never
seen it (or at least noticed it) before, and I don't do it
myself.
I'm curious as to why? Is it an intentional decision, or is it
based on some tool, or what?
Agreed. Like you, I've used different styles over time. The
important thing is that the code has an "expected" look; if you
change something, and that look isn't there, it strikes you
immediately. If the rule is "a flow control statement is
followed either by a single indented statement, or a { on a line
by itself, not indented", then adding a second statement just
doesn't look right unless you add the {.
============
It is strange, but in the message I posted, there was NOT an extra space
before the closing bracket. But you quote me with the space. I don't know
if it was your reader or not, but I look at my post and the extra space is
not there.
That is:
if ( condition )
{
statements
}
should be 4 lines. The if, left bracket, statements, right bracket. If you
see an extra line before the end bracket somethings amiss.
J
Jim Langston
BobR said:
At one point I indented the bracket and got used to it. But the main reason
I changed is because the auto formatting of my compiler doesn't indent the
bracket.
J
Jim Langston
Jim Langston said:
Of course I meant IDE and not compiler.
J
James Kanze
As I said, it goes back long before Unix. I first saw it in
Univac transmission protocol around 1975, and the protocol was
considered very outdated even then.
The relationship with Fortran might have something to do with
it, except that in Fortran (at least, the Fortran of the 1970's
and before), it would have been seven (as you point out).
For what it's worth, I tend to like 4 for tabs. That is probably
because I am both a programmer and old school. That is, I both like
that it is a power of 2 and I like that every two tabs matches up with
a "real" tab.
You mean you like 4 as a shift width. That's what I use, too.
In practice, changing tab stops from eight just isn't possible.
There's too much legacy software and equipment which has 8 built
in, and too much modern stuff which is built with 8 built in to
conform with the legacy equipment. Even most of Windows uses 8.
(The problem, of course, is that you don't just view your code
in the editor. You print it, you grep for things in it, you
diff it... And unless you can force all of your toolset to use
the non-standard tabstop, you're stuck.)
J
James Kanze
Wasting bytes wasn't commonly done, but program input was on 80
column punched cards---every line had exactly 80 characters in
it, like it or not. And the Fortran compilers I knew ignored
the last 8 (there comes that multiple again), so that you could
put sequence numbers in them, so that the deck could be
automatically resorted when you dropped it on the floor.
It's interesting to note that Cobol apparently followed
Fortran's example, with the first 7 columns being special. It
also distinguished an Area A (columns 8-11) and an Area B
(columns 12-72). None of which (except for the 72) reinforces
the 8 column tabs.
Some of the early assemblers I used did, however, treating
columns 1-8 as a label, 9-16 as a mnemonic, and 17 and up as the
arguments to the instruction.
J
James Kanze
[...]
That's a different issue: white space in a line. If you work in
Germany, you'll soon adapt to the second; if you learned
programming in France, the first will seem more natural. The
use of white space is at least partially influenced by local
typographical conventions; the conventions for French use
considerably more white space than those for most other
languages, and those for German somewhat less. The result is
that when I worked in Germany, many of my collegues felt ill at
ease with my style (and I with theirs); we finally wrote an
"unjames" emacs script which removed the extra spaces I put in.
One point worth mentionning is that the parentheses really have
three different roles in C/C++: they are used for grouping, as a
function call operator, or as a fundamental grammatic part of
some statements. I vary my spacing according to use:
x * (y + z) ; // grouping.
f( y + z ) ; // function call.
if ( y == z ) // part of statement.
Basically, spaces outside for grouping, spaces inside for a
function call (but with the ( tightly bound to the function
name), and spaces both inside and outside for part of a
statement.
This isn't, however, something that I would consider essential,
or that I would fight to have, and I have no problem with the
fact that my German collegues wouldn't have used a single space
in any of the examples above (except maybe before the comment).
That's a different issue: white space in a line. If you work in
Germany, you'll soon adapt to the second; if you learned
programming in France, the first will seem more natural. The
use of white space is at least partially influenced by local
typographical conventions; the conventions for French use
considerably more white space than those for most other
languages, and those for German somewhat less. The result is
that when I worked in Germany, many of my collegues felt ill at
ease with my style (and I with theirs); we finally wrote an
"unjames" emacs script which removed the extra spaces I put in.
One point worth mentionning is that the parentheses really have
three different roles in C/C++: they are used for grouping, as a
function call operator, or as a fundamental grammatic part of
some statements. I vary my spacing according to use:
x * (y + z) ; // grouping.
f( y + z ) ; // function call.
if ( y == z ) // part of statement.
Basically, spaces outside for grouping, spaces inside for a
function call (but with the ( tightly bound to the function
name), and spaces both inside and outside for part of a
statement.
This isn't, however, something that I would consider essential,
or that I would fight to have, and I have no problem with the
fact that my German collegues wouldn't have used a single space
in any of the examples above (except maybe before the comment).
J
James Kanze
[...]
Google again? That would explain why I see it a lot now (that
I'm using Google as a news reader), and never saw it before
(when I used Gnus, or for a very short time, Thunderbird).
I generally delete it when quoting a posting; I made an
exception this time, since it was the point of my posting.
A quick check with Google showed that my code shows up without
this extra blank line. However, I always indent the code in the
message (to set it off from the rest of the message), so the }
is never in the first column. Maybe that's what it takes to
trigger the Google thing (or whatever it is that's causing it).
Anyway, if it wasn't there to start with, then obviously, it's
not some new convention that's suddenly taking everything by
storm, so there's no problem. I'll just ignore it when I see
it, and continue to delete it when replying.
(I do wish Google would get Google news working correctly,
though. As it is, it crashes Firefox several times a week,
although I've never had Firefox crash on any other page. I
installed a debug version of Firefox, and caught their pages,
and there were so many violations of the HTML standard that I
didn't know where to start.)