Stylistic questions on UNIX C coding.
Poster Matt
I've a few questions concerning style when programming C on UNIX systems. I
don't want to look like an amateur. :)
1. Having been programming in higher level languages for the last 15 years, I'm
finding it hard to get used to DEFINES in all capitals. Is it really frowned on
not to do so? Is CamelCase acceptable?
EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
2. My personal variable and function naming style is camel case, with variable
names beginning with a lower case char and function names not. Is that
acceptable, if not what is?
EG:
Variables: int numFiles = 0;
Functions: int CountNumFilesInDir(char* path);
3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
120 chars I start thinking this might not look great in someone else's editor.
4. Does anyone care where the pointer * is? I prefer keeping to next to the
type, rather than next to the variable name.
EG. I like: char* firstName; and not so much: char *firstName;
5. On a slightly different note, I've been handling my error messages by using
#define string constants in a header file. I saw some code which did this and it
looked good to me. Is that standard practise, if not what is?
EG. #define ErrorDirNotFound "The directory was not found."
There are so many style guides out there, most of them say contradictory things
at one point or another. What do the pros do?
Finally, before someone points this out... I know if I'm coding for myself, and
not following somebody else's stylistic requirements, I can do whatever I want.
However I'd like my code to be 'acceptable looking' to the wider UNIX C community.
Thanks and regards, etc.
Julienne Walker
> Hi,
>
> I've a few questions concerning style when programming C on UNIX systems. I
> don't want to look like an amateur. :)
>
> 1. Having been programming in higher level languages for the last 15 years, I'm
> finding it hard to get used to DEFINES in all capitals. Is it really frowned on
> not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
All caps is merely a convention so that macros are easier to see. If
you don't want to follow that convention, feel free. Though keep in
mind that conventions are there for a reason. The preprocessor has
proven troublesome enough over the years to warrant having macros
stand out a bit. ;-)
> 2. My personal variable and function naming style is camel case, with variable
> names beginning with a lower case char and function names not. Is that
> acceptable, if not what is?
>
> EG:
> Variables: int numFiles = 0;
> Functions: int CountNumFilesInDir(char* path);
That's fine. I see that style often.
> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
> 120 chars I start thinking this might not look great in someone else's editor.
I try to keep each line under 100 characters (80 if possible). It's
less about monitor size than it is about easily reading my code at a
glance.
> 4. Does anyone care where the pointer * is? I prefer keeping to next to the
> type, rather than next to the variable name.
>
> EG. I like: char* firstName; and not so much: char *firstName;
Just make sure you're consistent and nobody will care. :-)
> 5. On a slightly different note, I've been handling my error messages by using
> #define string constants in a header file. I saw some code which did this and it
> looked good to me. Is that standard practise, if not what is?
>
> EG. #define ErrorDirNotFound "The directory was not found."
That's acceptable. Though keep in mind that in the age of
internationalization and localization, hard coding string literals
makes your code harder to port to other spoken languages.
> There are so many style guides out there, most of them say contradictory things
> at one point or another. What do the pros do?
The pros are just as contradictory as the style guides. Pick a style
you like and run with it, with the caveat that over time your tastes
(and as a result, your style) will evolve.
> Finally, before someone points this out... I know if I'm coding for myself, and
> not following somebody else's stylistic requirements, I can do whatever I want.
> However I'd like my code to be 'acceptable looking' to the wider UNIX C community.
You can make bad code look pretty and it's still bad code. But in my
experience, good code has never looked ugly. Good aesthetics seems to
come naturally if you focus on writing the best code possible.
Fred
Except that it is very error-prone to do so.
In C, the asterisk is associated with the variable name, not the type
specifier.
I've seen this so many times:
char* x, y;
Here, x a pointer to char, but y is a char.
Much clearer to show what you really intended:
char *x, *y; /* Both pointers */
or
char *x, y; /* One a pointer, one not */
>(snip)
--
Fred K
James Harris
> Hi,
>
> I've a few questions concerning style when programming C on UNIX systems. I
> don't want to look like an amateur. :)
As a fellow amateur in C....
> 1. Having been programming in higher level languages for the last 15 years, I'm
> finding it hard to get used to DEFINES in all capitals. Is it really frowned on
> not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
While I use them I don't like all caps for #defined values for two
reasons
1) #defined values don't seem to me too far removed from global
parameters. Indeed if we change them to parameters in a function call
they lose upper case status. The two uses are similar. To my mind the
format of the names should also be similar.
2) I'd prefer to reserve all caps for macros. Then they serve as a
warning that parameters are not guaranteed to be evaluated exactly
once.
Many libraries use all caps for their constants.
You could also define constants in enums rather than in #defines.
>
> 2. My personal variable and function naming style is camel case, with variable
> names beginning with a lower case char and function names not. Is that
> acceptable, if not what is?
You'll probably get advised to stick to whatever coding standards your
project team members use. Also, when changing someone else's code,
stick to the standards used therein. For your own projects you could
use
first_name
firstname
FirstName
firstName
> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
> 120 chars I start thinking this might not look great in someone else's editor.
Again, use existing coding standards if there are any. My monitor is
also wide but I prefer to keep to 80-columns because you never know
what size monitor the code will subsequently be edited on.
>
> 4. Does anyone care where the pointer * is? I prefer keeping to next to the
> type, rather than next to the variable name.
>
> EG. I like: char* firstName; and not so much: char *firstName;
It's normally as the latter due to
char* FirstName, ch, *p;
char *FirstName, ch, *p;
Regardless of which form is used I think only ch will be a char
variable - i.e. "char*" can be misleading. The other variables will be
pointers. Someone will correct me if I'm wrong. Though you are right
in principle, C does not cleanly segregate type and name. For example
int func(int);
This declares the name func but the type information is scattered all
over such declarations.
> 5. On a slightly different note, I've been handling my error messages by using
> #define string constants in a header file. I saw some code which did this and it
> looked good to me. Is that standard practise, if not what is?
>
> EG. #define ErrorDirNotFound "The directory was not found."
That's much better than sprinkling messages throughout the code. If
followed consistently it makes clear what messages the code can issue.
Apart from clarity that would help if you ever want to release your
code in another human language. There are better ways with more
mechanism.
You may need a way to include variable values in your messages.
>
> There are so many style guides out there, most of them say contradictory things
> at one point or another. What do the pros do?
>
> Finally, before someone points this out... I know if I'm coding for myself, and
> not following somebody else's stylistic requirements, I can do whatever I want.
> However I'd like my code to be 'acceptable looking' to the wider UNIX C community.
Check some examples: K&R2, C Unleashed, books by Douglas Comer, the
Linux source etc. Also there is a FAQ entry for style issues:
http://c-faq.com/style/index.html
James
Lew Pitcher
wrote:
> Hi,
>
> I've a few questions concerning style when programming C on UNIX systems.
> I don't want to look like an amateur. :)
>
> 1. Having been programming in higher level languages for the last 15
> years, I'm finding it hard to get used to DEFINES in all capitals. Is it
> really frowned on not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
CamelCase is acceptable, with the caveat that the programmer (you, or
whomever reads your code) should be able to distinguish the difference
between a macro and a variable.
> 2. My personal variable and function naming style is camel case, with
> variable names beginning with a lower case char and function names not. Is
> that acceptable, if not what is?
>
> EG:
> Variables: int numFiles = 0;
> Functions: int CountNumFilesInDir(char* path);
Again, CamelCase is acceptable.
> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I
> reach 120 chars I start thinking this might not look great in someone
> else's editor.
Somewhere around 80 characters per line is the norm. That facilitates both
on-screen review and editing as well as printing and emailing of code.
> 4. Does anyone care where the pointer * is? I prefer keeping to next to
> the type, rather than next to the variable name.
>
> EG. I like: char* firstName; and not so much: char *firstName;
That's acceptable, but prone to error.
Given
char* firstName lastName;
what is the type of <lastName>?
If you read the declaration and answered that <lastName> is of char* type,
then you would be wrong. The language groups type modifiers to the defined
object, and not to the base type. Visually grouping the modifiers contrary
to how the language groups them can lead to programmer mis-interpretation
and error.
> 5. On a slightly different note, I've been handling my error messages by
> using
> #define string constants in a header file. I saw some code which did this
> #and it
> looked good to me. Is that standard practise, if not what is?
>
> EG. #define ErrorDirNotFound "The directory was not found."
Most development groups I've worked with would find that practice
acceptable.
> There are so many style guides out there, most of them say contradictory
> things at one point or another. What do the pros do?
Usually, the pros do what the other pros that they are working with do.
Computer languages are a convenience to the /programmer/, not to the
computer. The rules (both at a language level, and at a developer level)
are set to make it easy for a programmer to write code, and for other
programmers to read (and often rewrite) it. So long as you apply your style
rules consistently (so that there are no unexpected deviations), things
should work out.
> Finally, before someone points this out... I know if I'm coding for
> myself, and not following somebody else's stylistic requirements, I can do
> whatever I want. However I'd like my code to be 'acceptable looking' to
> the wider UNIX C community.
/Which/ "UNIX C community"? Some communities have their own coding styles
("the one true style", or the K&R style, or the "Linux Kernel stye", for
instance), and no one set of rules will make your code acceptable to all of
the communities out there.
The best I can give you is to
a) be consistant, and
b) be simple
in your coding. Don't do the unexpected; once you've established a pattern,
stick with it until there is good reason to change. Document the change
ahead of time. Don't over-complicate things. The point is to make your code
easy to read and understand at the /human/ level.
> Thanks and regards, etc.
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------
Seebs
> 1. Having been programming in higher level languages for the last 15 years, I'm
> finding it hard to get used to DEFINES in all capitals. Is it really frowned on
> not to do so? Is CamelCase acceptable?
It'll work, but people will find it surprising. All-caps as a warning that
something is a macro or other manifest constant is pretty canonical.
But you'd normally spell that one "MAX_FILES".
> 2. My personal variable and function naming style is camel case, with variable
> names beginning with a lower case char and function names not. Is that
> acceptable, if not what is?
I dislike it, anyway. Convention is words_with_underscores().
> EG:
> Variables: int numFiles = 0;
> Functions: int CountNumFilesInDir(char* path);
Also, "Num" doesn't need to be there.
> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
> 120 chars I start thinking this might not look great in someone else's editor.
80ish is preferred. Lines exceeding 80 will generally not be accepted by a
lot of projects unless there's a VERY good reason.
> 4. Does anyone care where the pointer * is? I prefer keeping to next to the
> type, rather than next to the variable name.
> EG. I like: char* firstName; and not so much: char *firstName;
You are wrong.
I mean, sure, it compiles, but consider:
char* x, y;
By contrast:
char *x, y;
makes it clear that you are aware that the * modifies the variable, not the
type.
> 5. On a slightly different note, I've been handling my error messages by using
> #define string constants in a header file. I saw some code which did this and it
> looked good to me. Is that standard practise, if not what is?
> EG. #define ErrorDirNotFound "The directory was not found."
No. Look into gettext() if you need to do this, or just put them in
literally.
> There are so many style guides out there, most of them say contradictory things
> at one point or another. What do the pros do?
I use the Linux kernel style guide and/or the BSD style guide, which are
basically compatible. Ignore the GNU coding standards, they're awful.
> Finally, before someone points this out... I know if I'm coding for myself, and
> not following somebody else's stylistic requirements, I can do whatever I want.
> However I'd like my code to be 'acceptable looking' to the wider UNIX C community.
It's a good effort. I do have to say, though... It's odd that you've managed
a complete sweep of, for every stylistic decision described above, picking
the opposite of the general convention in the UNIX world. Where did you pick
up these preferences?
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Julienne Walker
> On Feb 24, 11:10 am, Julienne Walker <happyfro...@hotmail.com> wrote:
> > On Feb 24, 1:35 pm, Poster Matt <postermatt@no_spam_for_me.org> wrote:
>
> > > 4. Does anyone care where the pointer * is? I prefer keeping to next to the
> > > type, rather than next to the variable name.
>
> > > EG. I like: char* firstName; and not so much: char *firstName;
>
> > Just make sure you're consistent and nobody will care. :-)
>
> Except that it is very error-prone to do so.
It's only error prone if you have multiple variables in a declaration
statement (which the OP's example did not). That itself is often
viewed as an unsafe practice.
Rich Webb
<happy...@hotmail.com> wrote:
>On Feb 24, 1:35�pm, Poster Matt <postermatt@no_spam_for_me.org> wrote:
>> Hi,
>>
>> I've a few questions concerning style when programming C on UNIX systems. I
>> don't want to look like an amateur. :)
>> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
>> 120 chars I start thinking this might not look great in someone else's editor.
>
>I try to keep each line under 100 characters (80 if possible). It's
>less about monitor size than it is about easily reading my code at a
>glance.
Typographers, who study this thing with the fervor that programmers
bring to brace styles, would tend to agree. There are always reasonable
exceptions but a line length that's 70-80 characters (monospaced) seems
to be a sweet spot for comprehension.
>> 4. Does anyone care where the pointer * is? I prefer keeping to next to the
>> type, rather than next to the variable name.
>>
>> EG. I like: char* firstName; and not so much: char *firstName;
>
>Just make sure you're consistent and nobody will care. :-)
Except there's the danger in having one's thoughts focused elsewhere
when adding the next piece, and getting
char* firstName, lastName;
--
Rich Webb Norfolk, VA
Eric Sosman
> Hi,
>
> I've a few questions concerning style when programming C on UNIX
> systems. I don't want to look like an amateur. :)
>
> 1. Having been programming in higher level languages for the last 15
> years, I'm finding it hard to get used to DEFINES in all capitals. Is it
> really frowned on not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
All-caps is one of those conventions that's widely adopted,
although there's no inherent linguisic necessity for it (indeed,
some macros required by the C Standard itself are lower-case).
People are accustomed to seeing macro names in upper-case only,
and since macros can look like functions but behave differently
(consider `x = MIN(y,z)' vs `x = MIN(y, f_with_side_effects())'),
the coder must sometimes know which is being used. Recommendation:
Stick with upper-case macro names to forestall confusion.
> 2. My personal variable and function naming style is camel case, with
> variable names beginning with a lower case char and function names not.
> Is that acceptable, if not what is?
>
> EG:
> Variables: int numFiles = 0;
> Functions: int CountNumFilesInDir(char* path);
Use whatever works for you, and for the others who read the
same body of code. If you're working on existing code, stay with
whatever conventions it already uses. If you're writing new code
(that's not in association with existing code), use what you like.
> 3. Is there an accepted maximum line length? I've got a 24" monitor, if
> I reach 120 chars I start thinking this might not look great in someone
> else's editor.
Really long lines -- especially in blocks that cover several
consecutive lines -- can be hard to read because the eye may have
trouble maintaining vertical "registration" while flipping back
and forth between the end of one line and the start of the next --
oh, damn, I skipped down two again! Usual practice is to use
narrower lines than yours, allowing the line to be seen as a whole
rather than traced out in multiple horizontal jumps. Seventy to
eighty characters are a typical length (although that range is in
part due to hysterical raisins).
> 4. Does anyone care where the pointer * is? I prefer keeping to next to
> the type, rather than next to the variable name.
>
> EG. I like: char* firstName; and not so much: char *firstName;
If you're firm about declaring only one identifier per line,
this is fine. But the minute you write
char* firstPtr, finalPtr;
... you're going to be unpleasantly surprised.
> 5. On a slightly different note, I've been handling my error messages by
> using #define string constants in a header file. I saw some code which
> did this and it looked good to me. Is that standard practise, if not
> what is?
>
> EG. #define ErrorDirNotFound "The directory was not found."
This could turn out to be helpful in translating the messages
someday: "Das Verzeichnis wurde nicht gefunden." On the other hand,
there are more flexible ways to deal with this than to compile
separate versions for German, French, Klingon, ...
> There are so many style guides out there, most of them say contradictory
> things at one point or another. What do the pros do?
Contradict each other, of course! Why did you ask?
> Finally, before someone points this out... I know if I'm coding for
> myself, and not following somebody else's stylistic requirements, I can
> do whatever I want. However I'd like my code to be 'acceptable looking'
> to the wider UNIX C community.
From the Eighth Commandment: "... thy creativity is better
used in solving problems than in creating beautiful new impediments
to understanding." The Commandment speaks of brace styles, but
the point applies with equal force to other stylistic choices.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Chris Friesen
> Hi,
>
> I've a few questions concerning style when programming C on UNIX systems. I
> don't want to look like an amateur. :)
> There are so many style guides out there, most of them say contradictory things
> at one point or another. What do the pros do?
Your questions are valid, but the real answer is that it totally depends
on the project. If you're contributing to an existing project then you
should follow the coding standards already in place.
If you're starting something totally new, you can do whatever you want.
That said, most people will be familiar with a few of of the main
standard styles: linux kernel, K&R, GNU, etc. It may make sense to
pick one of those that closest matches your preferred style.
I spend most of my time in the kernel, so my answers would be:
1) #defines should be uppercase and words separated with underscores.
Uppercase is also used for enums and name-prefixes that follow a uniform
convention.
1a) Using CamelCase (aka StudlyCaps) is frowned upon partly because it
means that the word-based commands in various editors (emacs, for
instance) don't work properly.
2) lowercase everything separated by underscores
3) max line length is 80 char
4) pointer * is next to variable
5) error messages are in the code explicitly
Chris
Rainer Weikusat
> 1. Having been programming in higher level languages for the last 15
> years, I'm finding it hard to get used to DEFINES in all capitals. Is
> it really frowned on not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
The problem with the preprocessor is that it work at the level of
preprocessing tokens and this means that, if preprocessor macros don't
live in a unique namespace, unintended substitutions can happen
easily, for instance, of subroutine names, and errors caused by this
are difficult to track down.
[...]
> 2. My personal variable and function naming style is camel case, with
> variable names beginning with a lower case char and function names
> not. Is that acceptable, if not what is?
>
> EG:
> Variables: int numFiles = 0;
> Functions: int CountNumFilesInDir(char* path);
CamelCase was invented for the Xerox Alto whose keyboard didn't have
an underscore character. Since 'object oriented programming' was also
(mostly) invented in the same context, 'OO-programmers' of today still
work around this hardware deficiency of the 1970s.
TheReasonThatTextsAreNotWrittenLikeThisIsBecauseReadibiltyIsCrappyThen.
So_use_a_visually_distinct_separator_character. People using scripts
based on the Roman alphabet have abandoned the Roman writing
convention to not use separators more than thousand years ago. Don't
reinvent it.
[...]
> 4. Does anyone care where the pointer * is? I prefer keeping to next
> to the type, rather than next to the variable name.
>
> EG. I like: char* firstName; and not so much: char *firstName;
C knows about three kinds of derived types, arrays
char a[];
Pointers to functions
char (*a)();
and pointers
char *a;
Don't special-case on of these three cases because of a lack of
understanding of the C type system.
Lastly, please don't ask questions like this in public.
Keith Thompson
> I've a few questions concerning style when programming C on UNIX
> systems. I don't want to look like an amateur. :)
>
> 1. Having been programming in higher level languages for the last 15
> years, I'm finding it hard to get used to DEFINES in all capitals. Is
> it really frowned on not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
The convention is to use all-caps for macro names, unless you're
deliberately hiding the fact that something is a macro.
> 2. My personal variable and function naming style is camel case, with
> variable names beginning with a lower case char and function names
> not. Is that acceptable, if not what is?
>
> EG:
> Variables: int numFiles = 0;
> Functions: int CountNumFilesInDir(char* path);
A lot of people dislike camel case (my own preference is lower case
with underscores for most things), but it's a common and widely
accepted style. If you're working on an existing project, you should
follow the existing style (this applies to all these rules).
> 3. Is there an accepted maximum line length? I've got a 24" monitor,
> if I reach 120 chars I start thinking this might not look great in
> someone else's editor.
80 columns.
> 4. Does anyone care where the pointer * is? I prefer keeping to next
> to the type, rather than next to the variable name.
>
> EG. I like: char* firstName; and not so much: char *firstName;
The usual C style is
char *firstName;
The usual C++ style is
char* firstName;
There's no language-level reason for the difference; C and C++ syntax
are the same at this level. I think it's just that Kernighan and
Ritchie preferred the first form, and Stroustrup preferred the second.
If you're going to be programming in C, I recommend the first form,
both because it's the usual convention and because it follows the
syntax of the langauge. When the compiler parses:
char * firstName ;
"*" and "firstName" are grouped together. What the declaration really
means is that the expression "*firstName" is of type char; it follows
from this that firstName is of type char*. C declarations usually
follow a "declaration follows use" format (though not 100%
consistently).
If you choose to use the second style, you should avoid declaring
multiple objects in a single declaration. Others have pointed out
that this:
char* foo, bar;
is either misleading or wrong. The solution, whichever style you
use, is to declare foo and bar separately:
char *foo; /* or char* foo; if you insist */
char bar;
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
BruceS
> On 2010-02-24, Poster Matt <postermatt@no_spam_for_me.org> wrote:
> > 2. My personal variable and function naming style is camel case, with variable
> > names beginning with a lower case char and function names not. Is that
> > acceptable, if not what is?
>
> I dislike it, anyway. Convention is words_with_underscores().
>
> > EG:
> > Variables: int numFiles = 0;
> > Functions: int CountNumFilesInDir(char* path);
FWIW, I prefer the camel case style, though I don't capitalize
function names. If I'm maintaining someone else's code (and don't
expect to take it over), I follow their style. If I'm working with a
team, the team usually agrees on a style.
<snip>
> > 4. Does anyone care where the pointer * is? I prefer keeping to next to the
> > type, rather than next to the variable name.
> > EG. I like: char* firstName; and not so much: char *firstName;
>
> You are wrong.
>
> I mean, sure, it compiles, but consider:
>
> char* x, y;
>
> By contrast:
> char *x, y;
> makes it clear that you are aware that the * modifies the variable, not the
> type.
Absolutely with Seebs on this. The first style clearly implies that x
and y are both pointers to characters.
<snip>
I would like to add that, as long as you're trying to use good style,
for God's sake don't use the wrong indentation style. If you put your
opening braces on the same line as your conditional, you'll just look
like a fool in front of your friends and colleagues.
Keith Thompson
> Poster Matt <postermatt@no_spam_for_me.org> writes:
[...]
>> 4. Does anyone care where the pointer * is? I prefer keeping to next
>> to the type, rather than next to the variable name.
>>
>> EG. I like: char* firstName; and not so much: char *firstName;
>
> C knows about three kinds of derived types, arrays
>
> char a[];
>
> Pointers to functions
>
> char (*a)();
>
> and pointers
>
> char *a;
Array types, structure types, union types, function types, and pointer
types are all derived types (C99 6.2.5).
> Don't special-case on of these three cases because of a lack of
> understanding of the C type system.
But it might be acceptable to special-case on some cases *with*
an understanding of the C type system. I prefer "char *a;" myself,
but there's a valid argument that "char* a;" makes it more obvious
that's meant (that a is of type char*). As long as you also avoid
declaring multiple objects in a single declaration, it doesn't
necessarily cause any problems.
> Lastly, please don't ask questions like this in public.
Why not? Or are you just being rude?
James Harris
...
> I would like to add that, as long as you're trying to use good style,
> for God's sake don't use the wrong indentation style. If you put your
> opening braces on the same line as your conditional, you'll just look
> like a fool in front of your friends and colleagues.
Snobbish nonsense!
William Hughes
> There are so many style guides out there, most of them say contradictory things
> at one point or another. What do the pros do?
Among other things write style guides.
(i.e. what makes you think the pros are
not contradictory)
The only near universal conventions that I can
identify are
- macros should be upper case
- lines should not exceed 80 characters
For the rest, choose what you are most comfortable
with, always remembering that good code comes first.
(There have been lots of pros and cons pointed
out for your chosen style. I have little to add;
putting all error strings in one place seems
like a good idea, but something a little more flexible
than simple macros would seem in order.)
- William Hughes
Ersek, Laszlo
> On 2010-02-24, Poster Matt <postermatt@no_spam_for_me.org> wrote:
>> 1. Having been programming in higher level languages for the last 15 years, I'm
>> finding it hard to get used to DEFINES in all capitals. Is it really frowned on
>> not to do so? Is CamelCase acceptable?
>
> It'll work, but people will find it surprising. All-caps as a warning that
> something is a macro or other manifest constant is pretty canonical.
>
> But you'd normally spell that one "MAX_FILES".
(
And not FILES_MAX, as _MAX is a reserved suffix (in the X/Open (or
POSIX) Name Space).
http://www.opengroup.org/onlinepubs/007908775/xsh/compilation.html#tag_000_002_001
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_02
)
>> 2. My personal variable and function naming style is camel case, with variable
>> names beginning with a lower case char and function names not. Is that
>> acceptable, if not what is?
>
> I dislike it, anyway. Convention is words_with_underscores().
I agree. However, I'd like to mention, as a counter-example, some C
language X client libs using CamelCase.
http://en.wikipedia.org/wiki/Xlib
http://en.wikipedia.org/wiki/Intrinsics
http://en.wikipedia.org/wiki/Motif_(widget_toolkit)
>> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
>> 120 chars I start thinking this might not look great in someone else's editor.
>
> 80ish is preferred. Lines exceeding 80 will generally not be accepted by a
> lot of projects unless there's a VERY good reason.
Yes, a source formatted 80 columns wide works nicely on a character
console. And on a 24" TFT in 1920x1200, you can put two such windows
side by side, or have a web browser or a PDF viewer open beside the
source window, or diff two versions side by side without having to
scroll horizontally.
>> 5. On a slightly different note, I've been handling my error messages by using
>> #define string constants in a header file. I saw some code which did this and it
>> looked good to me. Is that standard practise, if not what is?
>
>> EG. #define ErrorDirNotFound "The directory was not found."
>
> No. Look into gettext() if you need to do this, or just put them in
> literally.
Or, for a bit more portable (and harder to use) approach:
http://www.opengroup.org/onlinepubs/007908775/xsh/catopen.html
http://www.opengroup.org/onlinepubs/007908775/xcu/gencat.html
The idea is that you translate printf() style format strings into
different natural languages, making heavy use of %n$ "position
specifiers", so that you can change the order the arguments are printed
in, without changing the order they are passed to *printf() (ie. without
changing the code).
http://www.opengroup.org/onlinepubs/007908775/xsh/fprintf.html#tag_000_008_809
catgets() allows/forces the programmer to supply a default string, which
is very useful.
(Not that I'd believe in software internationalization at all, having
seen *no* software correctly *and* understandably translated from
English to Hungarian, for example.)
> It's odd that you've managed
> a complete sweep of, for every stylistic decision described above, picking
> the opposite of the general convention in the UNIX world. Where did you pick
> up these preferences?
I'd have guessed Java, but as Rainer Weikusat points out in
<87d3zuf...@fever.mssgmbh.com>, CamelCase and co. originate from
much earlier. (Thanks for the interesting historical tidbit, Rainer!)
Cheers,
lacos
Ersek, Laszlo
I've actually laughed out loud when I've read Bruce's part above; it's
so blatant that I'm almost completely sure it was meant as irony.
(Perhaps so is your response, too.)
Cheers,
lacos
Stephen Sprunk
> I've a few questions concerning style when programming C on UNIX
> systems. I don't want to look like an amateur. :)
The biggest mistakes that newbies make are lack of consistency and
trying to change others' style. If you're contributing to an existing
project, follow whatever established style it has, period.
If you're starting a new project, pick one of the common styles in other
projects you've seen and like. Do not modify (or "customize") the style
unless you can competently explain _why_ it does things the way it does
and you can demonstrate (to people more skilled than you) that your
change is an improvement for your particular project.
Do not invent your own style.
> 1. Having been programming in higher level languages for the last 15
> years, I'm finding it hard to get used to DEFINES in all capitals. Is it
> really frowned on not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
This is canonical and is done in all of the various styles I've seen.
There are very good reasons for that.
(It's more important for function-like macros, where you may need to
warn the user that arguments may be evaluated multiple times. OTOH,
function-like macros that mask a true function must use the case of the
function they mask, but must take care not to do multiple evaluation.)
> 2. My personal variable and function naming style is camel case, with
> variable names beginning with a lower case char and function names not.
> Is that acceptable, if not what is?
>
> EG:
> Variables: int numFiles = 0;
This is camelCase.
> Functions: int CountNumFilesInDir(char* path);
This is PascalCase.
Mixing the two in the same project will drive adherents of _both_ styles
nuts. Pick one and stick to it; that way you'll only drive half of your
readers nuts.
(There's also this_type_of_identifier; the same logic applies, i.e.
don't mix that with either of the above. Never, never create some
God-awful hybrid with both underscores and uppercase letters...)
Some mixing is unavoidable if you call libraries that use different
styles, but don't deliberately make it worse.
> 3. Is there an accepted maximum line length? I've got a 24" monitor, if
> I reach 120 chars I start thinking this might not look great in someone
> else's editor.
Do not go over 80 columns without a very, very good reason.
If that presents a serious problem (i.e. more than the occasional
complicated function call or if expression), there's probably something
wrong with your code anyway.
> 4. Does anyone care where the pointer * is? I prefer keeping to next to
> the type, rather than next to the variable name.
>
> EG. I like: char* firstName; and not so much: char *firstName;
The latter is canonical in all styles. If you use the former, one day
you'll write "char* firstName, lastName;" and cause all sorts of problems.
> 5. On a slightly different note, I've been handling my error messages by
> using #define string constants in a header file. I saw some code which
> did this and it looked good to me. Is that standard practise, if not
> what is?
>
> EG. #define ErrorDirNotFound "The directory was not found."
Either put the string inline or use some facility such as gettext(),
which is better for later i18n issues anyway.
> There are so many style guides out there, most of them say contradictory
> things at one point or another. What do the pros do?
See comments at top.
> Finally, before someone points this out... I know if I'm coding for
> myself, and not following somebody else's stylistic requirements, I can
> do whatever I want. However I'd like my code to be 'acceptable looking'
> to the wider UNIX C community.
If your code will be read by someone else, you want the style to seem
familiar enough to them that it won't distract them from being able to
read what the code _means_; that generally means picking one of the
common styles even if it's not ideal according to your tastes.
If you're absolutely sure _nobody_ will _ever_ read your code, do
whatever you want--but I'd recommend picking a common style anyway just
in case you're wrong. People usually are about such things, eventually.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
William Hughes
> I would like to add that, as long as you're trying to use good style,
> for God's sake don't use the wrong indentation style. If you put your
> opening braces on the same line as your conditional, you'll just look
> like a fool in front of your friends and colleagues.
You need to fix your misprint. Clearly you meant
If you *dont* put your opening braces on
the same line as your conditional, you'll
just look like a fool in front of your
friends and colleagues.
- William Hughes
Scott Lurndal
>Hi,
>
>I've a few questions concerning style when programming C on UNIX systems. I
>don't want to look like an amateur. :)
>
>1. Having been programming in higher level languages for the last 15 years, I'm
>finding it hard to get used to DEFINES in all capitals. Is it really frowned on
>not to do so? Is CamelCase acceptable?
>
>EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
Well, defines are macros, not constants, so I try to avoid them for this use.
With C99 and C++, one should probably use static const
<type> (where type a signed or unsigned integer of the appropriate width).
e.g.
static const unsigned int MaxNumFiles = 1024;
For C++, the visibility should be the most restrictive possible
(i.e. private if the constant is only used by class members).
This allows the compiler to use more strict type checking with the
constants, and signedness is explicit.
>
>
>2. My personal variable and function naming style is camel case, with variable
>names beginning with a lower case char and function names not. Is that
>acceptable, if not what is?
>
>EG:
>Variables: int numFiles = 0;
>Functions: int CountNumFilesInDir(char* path);
There are many different conventions; I prefer underscores myself.
I also prefer
int
count_dir_entries(const char *path)
or
inline int
c_class::count_dir_entries(const char *path)
(With vi/vim, ^functioname will move the cursor to start of
the function if it starts the line).
>
>
>3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
>120 chars I start thinking this might not look great in someone else's editor.
>
80. Please.
>
>5. On a slightly different note, I've been handling my error messages by using
>#define string constants in a header file. I saw some code which did this and it
>looked good to me. Is that standard practise, if not what is?
>
>EG. #define ErrorDirNotFound "The directory was not found."
Bad practice. The string value will be duplicated in every compilation
unit that uses it. Better is to have a function that returns a const char *
given an error message number (e.g. strerror(3)).
In general, for your own code, follow what you like (or your employer requires).
If you are modifying existing code, follow the existing style.
scott
Scott Lurndal
>On 24 Feb, 20:53, BruceS <bruce...@hotmail.com> wrote:
>
>...
>
>> I would like to add that, as long as you're trying to use good style,
>> opening braces on the same line as your conditional, you'll just look
>> like a fool in front of your friends and colleagues.
>
>Snobbish nonsense!
>
>
Indeed.
if (condition) {
is preferred over
if (condition)
{
Makes it much more likely that a properly written function will fit on a single
page/screen.
In 30 years of C programming, no employer or project has used the latter form.
scott
Scott Lurndal
>On 02/24/2010 12:35 PM, Poster Matt wrote:
>5) error messages are in the code explicitly
In order to effectively i18n the code, this practice should
be avoided. Rather, one should use gettext or equiv.
scott
Anand Hariharan
wrote:
> Hi,
>
> I've a few questions concerning style when programming C on UNIX systems. I
> don't want to look like an amateur. :)
>
> 1. Having been programming in higher level languages for the last 15 years, I'm
> finding it hard to get used to DEFINES in all capitals. Is it really frowned on
> not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
>
As see from the umpteen replies, you are not going to get one answer
when it comes to a style-related question.
Haven't seen anyone point this out:
Rather than -
#define MAXNUMFILES 1024
- prefer -
const int MaxNumFiles = 1024;
That way your preprocessor won't do as much damage.
Ersek, Laszlo
> static const unsigned int MaxNumFiles = 1024;
>
> [...]
>
> This allows the compiler to use more strict type checking with the
> constants, and signedness is explicit.
#define MAX_FILES 1024u
#define BUFSIZE ((size_t)4096)
(Yes, when I *use* MAX_FILES, I don't necessarily remember its type. But
in that situation the same applies to "MaxNumFiles": we have to look up
the definition.)
Signedness is equally explicit in
#define MAX_FILES 1024
as 1024 is ((int)1024) -- that macro definition is just ugly.
Cheers,
lacos
Richard Heathfield
<snip>
>
> if (condition) {
>
> is preferred over
>
> if (condition)
> {
Except, of course, by people who prefer the latter to the former.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Richard Heathfield
<snip>
> Haven't seen anyone point this out:
>
> Rather than -
>
> #define MAXNUMFILES 1024
>
> - prefer -
>
> const int MaxNumFiles = 1024;
>
>
> That way your preprocessor won't do as much damage.
Fine in C99, I think, but an issue in C90 if he's using it to define an
array size.
Keith Thompson
>> EG:
>> Variables: int numFiles = 0;
>
> This is camelCase.
>
>> Functions: int CountNumFilesInDir(char* path);
>
> This is PascalCase.
>
> Mixing the two in the same project will drive adherents of _both_ styles
> nuts. Pick one and stick to it; that way you'll only drive half of your
> readers nuts.
His convention apparently is to use camelCase for variables and
PascalCase for functions. It's not necessarily a style I'd use, but
it's not obviously horrible (and it's more or less the style I use
at work). As with most of these rules, conforming to existing code
is far more important than any benefits of one style over another.
I really dislike the brace placement of the code I work on, but
mixing my own style into it would be far worse (and wouldn't survive
a code review anyway).
> (There's also this_type_of_identifier; the same logic applies, i.e.
> don't mix that with either of the above. Never, never create some
> God-awful hybrid with both underscores and uppercase letters...)
Again, This_Type_Of_Identifier isn't obviously horrible. (I use it
myself, though not in C.)
[...]
Anand Hariharan
> Anand Hariharan wrote:
>
> <snip>
>
> > Haven't seen anyone point this out:
>
> > Rather than -
>
> > #define MAXNUMFILES 1024
>
> > - prefer -
>
> > const int MaxNumFiles = 1024;
>
> > That way your preprocessor won't do as much damage.
>
> Fine in C99, I think, but an issue in C90 if he's using it to define an
> array size.
>
Good point (and that's probably why no one mentioned it?). Even in
C99, it is not your good old array but a 'Variable' Length Array.
Does the standard have anything to say about VLAs being automatic
storage or free store, but cleans itself up when they go out of scope?
Ben Bacarisse
> Anand Hariharan wrote:
> <snip>
>
>> Haven't seen anyone point this out:
>>
>> Rather than -
>>
>> #define MAXNUMFILES 1024
>>
>> - prefer -
>>
>> const int MaxNumFiles = 1024;
>>
>>
>> That way your preprocessor won't do as much damage.
>
> Fine in C99, I think, but an issue in C90 if he's using it to define
> an array size.
It's a problem in C99 too, if the array is defined at file scope or it
has internal linkage. There are other reasons why it's not a great
idea in C99. They stem from the fact that MaxNumFiles is not
permitted as part of a constant expression. There are several slight
variations depending on what sort of constant expression is required
but I think the simplest things is to say that using the above will
confuse someone sometime and is therefore not usually considered good
style even in C99.
--
Ben.
Rainer Weikusat
> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>> Poster Matt <postermatt@no_spam_for_me.org> writes:
> [...]
>>> 4. Does anyone care where the pointer * is? I prefer keeping to next
>>> to the type, rather than next to the variable name.
>>>
>>> EG. I like: char* firstName; and not so much: char *firstName;
>>
>> C knows about three kinds of derived types, arrays
>>
>> char a[];
>>
>> Pointers to functions
>>
>> char (*a)();
>>
>> and pointers
>>
>> char *a;
>
> Array types, structure types, union types, function types, and pointer
> types are all derived types (C99 6.2.5).
Exercise for the reader: Which of the six types defined above are
irrelevant for this statement about 'declaration of derived types'
because they belong to a different syntactical class than the three
examples? Which type is irrelevant because it cannot directly appear
in a variable declaration? Which other class of types should appear
instead because they can?
>> Don't special-case on of these three cases because of a lack of
>> understanding of the C type system.
>
> But it might be acceptable to special-case on some cases *with*
> an understanding of the C type system. I prefer "char *a;" myself,
> but there's a valid argument that "char* a;" makes it more obvious
> that's meant (that a is of type char*).
A type 'char*' doesn't exist. A type named 'char' does, and assuming
that T names an existing type, an object can be declared as 'pointer
to a T' by using the syntax
T *o;
'Pointerness' is an attribute of the object, not of the type. This is
also consistent with the original intention behind this syntax, namely
that 'declaration should resemble use'.
[...]
>> Lastly, please don't ask questions like this in public.
>
> Why not? Or are you just being rude?
They are bound to end up as quite useless quarrels between people
who desire to write "beautiful" code and people who desire to write
readable code.
Keith Thompson
> Poster Matt <postermatt@no_spam_for_me.org> writes:
[...]
>> years, I'm finding it hard to get used to DEFINES in all
>> capitals. Is it really frowned on not to do so? Is CamelCase
>> acceptable?
>>
>> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
I agree that MAXNUMFILES is harder to read than MaxNumFiles. The
solution is to write it as MAX_NUM_FILES.
> Well, defines are macros, not constants, so I try to avoid them for this use.
> With C99 and C++, one should probably use static const
> <type> (where type a signed or unsigned integer of the appropriate width).
[...]
Even in C99, the name of a static const object cannot be used as a
constant expression. This:
static const int max = 42;
int arr[max];
is valid in C99, but only because arr is a VLA (though the compiler
might implement it exactly as if it were a non-VLA). But max can't be
used in other contexts that requires a constant expression, such as
case labels.
A common trick is to use enum:
enum { max = 42 };
This has the drawback that it can only be of type int.
Keith Thompson
[...]
> His convention apparently is to use camelCase for variables and
> PascalCase for functions. It's not necessarily a style I'd use, but
> it's not obviously horrible (and it's more or less the style I use
> at work).
On re-reading, I realize that sounds a bit odd. What I meant is that
it's not necessarily a style I'd use *voluntarily*, but I have no
problem using it if it's necessary to conform to the existing style of
the code I'm working on.
ImpalerCore
You both are wrong. It's best to mix the two styles, to get the best
of both worlds.
if ( conditional ) {
// line of code
} else {
// line of code
}
if ( conditional )
{
// multiple
// lines
// of
// code
}
else
{
// multiple
// lines
// of
// code
}
if ( conditional ) {
// line of code
}
else
{
// multiple
// lines
// of
// code
}
and yes this is actually my personal style :P
Keith Thompson
> Keith Thompson <ks...@mib.org> writes:
>> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>> [...]
>>>> 4. Does anyone care where the pointer * is? I prefer keeping to next
>>>> to the type, rather than next to the variable name.
>>>>
>>>> EG. I like: char* firstName; and not so much: char *firstName;
>>>
>>> C knows about three kinds of derived types, arrays
>>>
>>> char a[];
>>>
>>> Pointers to functions
>>>
>>> char (*a)();
>>>
>>> and pointers
>>>
>>> char *a;
>>
>> Array types, structure types, union types, function types, and pointer
>> types are all derived types (C99 6.2.5).
>
> Exercise for the reader: Which of the six types defined above are
> irrelevant for this statement about 'declaration of derived types'
> because they belong to a different syntactical class than the three
> examples? Which type is irrelevant because it cannot directly appear
> in a variable declaration? Which other class of types should appear
> instead because they can?
You said that "C knows about three kinds of derived types". In fact,
there are six. I was disputing the accuracy of your statement, not
its relevance.
>>> Don't special-case on of these three cases because of a lack of
>>> understanding of the C type system.
>>
>> But it might be acceptable to special-case on some cases *with*
>> an understanding of the C type system. I prefer "char *a;" myself,
>> but there's a valid argument that "char* a;" makes it more obvious
>> that's meant (that a is of type char*).
>
> A type 'char*' doesn't exist. A type named 'char' does, and assuming
> that T names an existing type, an object can be declared as 'pointer
> to a T' by using the syntax
>
> T *o;
>
> 'Pointerness' is an attribute of the object, not of the type. This is
> also consistent with the original intention behind this syntax, namely
> that 'declaration should resemble use'.
Wrong. char* is a type. Specifically, it's a derived type and a
pointer type. See C99 6.2.5, particularly paragraph 20.
If char* is not a type, can you explain what exactly you mean when you
use the word "type"? Your usage appears to be inconsistent with the
usage in the C standard.
You might have a valid point in there somewhere, but your misuse of
terminology makes it difficult to discuss it.
(And for the record, I agree that "T *o;" is preferable to
"T* o;"; I just don't agree that it's a huge deal.)
> [...]
>
>>> Lastly, please don't ask questions like this in public.
>>
>> Why not? Or are you just being rude?
>
> They are bound to end up as quite useless quarrels between people
> who desire to write "beautiful" code and people who desire to write
> readable code.
Perhaps, but we've also seen some useful discussion in this thread,
particularly the point about the importance of conforming to whatever
coding standard is used for an existing project.
Jonathan de Boyne Pollard
>>
>> Lastly, please don't ask questions like this in public.
>>
> Why not? Or are you just being rude?
>
practiced behind closed doors by consenting adults only.
I saw the subject of the first post in this thread, and immediately
thought that there's a quick way to get one of the largest threads in
the newsgroup.
Lorenzo Villari
sc...@slp53.sl.home (Scott Lurndal) wrote:
>
> if (condition) {
>
> is preferred over
>
> if (condition)
> {
>
> Makes it much more likely that a properly written function will fit
> on a single page/screen.
Hmmm...
if (condition) { <-- one line
if (condition) <-- one line
{ <-- and another one, makes two lines
Does that really make a BIG difference?
>
> In 30 years of C programming, no employer or project has used the
> latter form.
Really? What's so bad about that? I prefer the latter btw...
Ian Collins
> James Harris <james.h...@googlemail.com> writes:
>> On 24 Feb, 20:53, BruceS <bruce...@hotmail.com> wrote:
>>
>> ...
>>
>>> I would like to add that, as long as you're trying to use good style,
>>> for God's sake don't use the wrong indentation style. =A0If you put your
>>> opening braces on the same line as your conditional, you'll just look
>>> like a fool in front of your friends and colleagues.
>> Snobbish nonsense!
>>
>>
>
> Indeed.
>
> if (condition) {
>
> is preferred over
>
> if (condition)
> {
By whom?
> Makes it much more likely that a properly written function will fit on a single
> page/screen.
If the extra lines required for an opening brace are an issue, the
function isn't properly written!
> In 30 years of C programming, no employer or project has used the latter form.
I can honestly negate that line.
--
Ian Collins
Richard Heathfield
> Scott Lurndal wrote:
<snip>
>> if (condition) {
>>
>> is preferred over
>>
>> if (condition)
>> {
>
> By whom?
Scott Lurndal (and plenty of other people, of whom I am not one).
<snip>
>> In 30 years of C programming, no employer or project has used the
>> latter form.
>
> I can honestly negate that line.
In fairness to Scott, I think he just intended to describe his personal
experience. In my own experience, Allman style (i.e. the latter of the
two styles quoted above) is almost universal. I can't actually call to
mind a single project where 1TBS was used - but there must have been at
least one; my memory isn't what it... um... ah!... was.
Ike Naar
Scott Lurndal <sl...@pacbell.net> wrote:
>
> if (condition) {
>
>is preferred over
>
> if (condition)
> {
>
>Makes it much more likely that a properly written function will fit on
>a single page/screen.
And then there are people who write like this:
if (condition) {
do_something();
do_another_thing();
}
Rainer Temme
> And then there are people who write like this:
>
> if (condition) {
>
> do_something();
> do_another_thing();
> }
or like this:
if (condition)
{
do_something();
do_another_thing();
}
or even like this:
if (condition) { do_something(); do_another_thing(); }
... the world is a cruel place!
Richard Bos
> I would like to add that, as long as you're trying to use good style,
> for God's sake don't use the wrong indentation style. If you put your
> opening braces on the same line as your conditional, you'll just look
> like a fool in front of your friends and colleagues.
Yeah. Those Kernighan and Ritchie guys knew jack shit about C.
Richard
Richard Bos
> On 2010-02-24, Poster Matt <postermatt@no_spam_for_me.org> wrote:
> > 5. On a slightly different note, I've been handling my error messages by using
> > #define string constants in a header file. I saw some code which did this and it
> > looked good to me. Is that standard practise, if not what is?
>
> > EG. #define ErrorDirNotFound "The directory was not found."
>
> No. Look into gettext() if you need to do this, or just put them in
> literally.
gettext() is nice if you have it (it's POSIX, isn't it? Not ISO, anyway,
but common), but putting the messages in literally only works if you
don't reuse them. IME, _some_ error messages are used more than once, in
which case a #define is nice.
Richard
ImpalerCore
> On 24 Feb 2010 22:09:43 GMT
>
> sc...@slp53.sl.home (Scott Lurndal) wrote:
>
> > if (condition) {
>
> > is preferred over
>
> > if (condition)
> > {
>
> > Makes it much more likely that a properly written function will fit
> > on a single page/screen.
>
> Hmmm...
>
> if (condition) { <-- one line
>
> if (condition) <-- one line
> { <-- and another one, makes two lines
>
> Does that really make a BIG difference?
>
The only time it bugs me is when I have a single line of code for an
if and else statement.
if ( condition )
{
// line
}
else
{
// other line
}
I used to use this for a while. But I tried the other convention and
ended up liking it better. Again, this is for my personal stuff; if a
style is already in place in a project, I follow that standard.
I also don't leave out braces though for single lines since I've been
bitten by that in the past.
if ( condition )
// line
I always do this
if ( condition ) {
// line
Stefan Monnier
> if (condition) {
> is preferred over
> if (condition)
> {
> Makes it much more likely that a properly written function will fit on
> a single page/screen.
> In 30 years of C programming, no employer or project has used the
> latter form.
The standard GNU style (i.e. recommended for GNU projects) is to use
if (condition)
{
blabla
}
so Emacs uses this style. I personnally prefer the single-line form (my
windows never have enough lines), so I hacked up some .emacs thingy that
makes the two-line form display as the one-line form.
Stefan
Malcolm McLean
>
>
> Yeah. Those Kernighan and Ritchie guys knew jack shit about C.
>
if it were the first pot ever made, would prove him a dunce if it came
after many millenia of pot-making.
Anand Hariharan
>
> if (condition) {
>
> is preferred over
>
> if (condition)
> {
>
> Makes it much more likely that a properly written function will fit on a single
> page/screen.
>
> In 30 years of C programming, no employer or project has used the latter form.
>
> scott
You've gotten some strong reactions to your not-seen-in-30-years
comment above.
FWIW I use the latter form myself. However, one good reason I got
from an ex-colleague for using the first style was that if you are
scrolling upward in source code, and get to the closing brace of a
block, using the keyboard shortcut in your editor for jumping to the
matching brace will get you to see the if (or while or for)
condition. Otherwise, it will only scroll upward to a point where the
opening brace is shown as the first line, and one has to go up one
line more. To me, this is not a big inconvenience.
- Anand
Seebs
> In fairness to Scott, I think he just intended to describe his personal
> experience. In my own experience, Allman style (i.e. the latter of the
> two styles quoted above) is almost universal. I can't actually call to
> mind a single project where 1TBS was used - but there must have been at
> least one; my memory isn't what it... um... ah!... was.
The two that come to mind are Linux and NetBSD. :)
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
BruceS
> In article <7f8b94fc-a78e-4c64-becf-f70a3843d...@o3g2000yqb.googlegroups.com>, James Harris <james.harri...@googlemail.com> writes:
>
> > On 24 Feb, 20:53, BruceS <bruce...@hotmail.com> wrote:
>
> > ...
>
> >> for God's sake don't use the wrong indentation style. If you put your
> >> opening braces on the same line as your conditional, you'll just look
> >> like a fool in front of your friends and colleagues.
>
>
> I've actually laughed out loud when I've read Bruce's part above; it's
> so blatant that I'm almost completely sure it was meant as irony.
> (Perhaps so is your response, too.)
>
> Cheers,
> lacos
Well *someone* laughed anyway. Yes, this was intended ironically, and
I thought it was so obvious that I didn't put in an emoticon. This is
one of the oldest pointless battles in C. Now it looks like I've
started it again, rather than the intended humor. I would have said
something about the inferiority of little-endianism, but I'm afraid
few people really get that.
Years ago, I had my one and only protest shirt. It said, in big
letters, "STOP PLATE TECTONICS". So many people were confused by it I
almost gave up wearing it. Then one Saturday, a manager at my work
started to walk past me, stopped to double-check what my shirt said,
and walked on laughing heartily.
Richard Heathfield
> On 2010-02-25, Richard Heathfield <r...@see.sig.invalid> wrote:
>> In fairness to Scott, I think he just intended to describe his personal
>> experience. In my own experience, Allman style (i.e. the latter of the
>> two styles quoted above) is almost universal. I can't actually call to
>> mind a single project where 1TBS was used - but there must have been at
>> least one; my memory isn't what it... um... ah!... was.
>
> The two that come to mind are Linux and NetBSD. :)
:-) Well, again I was referring only to my own experience. I haven't
actually worked on the source base to those two particular OSen. (Or
indeed any other mainstream OSen, come to that.)
BruceS
wrote:
That's a good one; I'll try to remember it.
FWIW, the K&R bit was intentional, to make the joke more obvious. Not
obvious enough for some, but apparently I either overestimated the
volume in the ng, or underestimated the mass. My bad.
Tom St Denis
The only reason I don't use the two-liner is that it's two lines. If
you write functions with a lot of conditionals (e.g. you're calling
functions that can fail) it adds up really quickly. It's also another
line you have to indent properly [something a lot of people don't do].
There is no technical reason beyond that for favouring either.
Personally I use the one-liner but I'll work on code that uses the
other. If I take ownership of code that uses the two liner I might
switch it back to one-liner but beyond that I'm not that petty :-)
my two cents...
Tom
Richard Heathfield
Is it not possible that you underestimated the gravity of the situation?
Poster Matt
> On Feb 24, 2:21 pm, Fred <fred.l.kleinschm...@boeing.com> wrote:
>> On Feb 24, 11:10 am, Julienne Walker <happyfro...@hotmail.com> wrote:
>>> On Feb 24, 1:35 pm, Poster Matt <postermatt@no_spam_for_me.org> wrote:
>>>> 4. Does anyone care where the pointer * is? I prefer keeping to next to the
>>>> type, rather than next to the variable name.
>>>> EG. I like: char* firstName; and not so much: char *firstName;
>> Except that it is very error-prone to do so.
>
> It's only error prone if you have multiple variables in a declaration
> statement (which the OP's example did not). That itself is often
> viewed as an unsafe practice.
OP here... Yes and agreed. My view is that each variable should have it's own
line. The only exception I make is when a for loop needs 2 index variables and
both are initiated in the for loop statement. EG:
int i, j;
for (i = pos, j = 0; ...)
John Bode
wrote:
> Hi,
>
> I've a few questions concerning style when programming C on UNIX systems. I
> don't want to look like an amateur. :)
>
> 1. Having been programming in higher level languages for the last 15 years, I'm
> finding it hard to get used to DEFINES in all capitals. Is it really frowned on
> not to do so? Is CamelCase acceptable?
>
> EG. '#define MaxNumFiles 1024' not '#define MAXNUMFILES 1024'.
>
The all-caps convention makes it easier to distinguish preprocessor
macros from other symbols. This can matter, especially when using
function-like macros (macros that take arguments). Remember that
macro expansions are simple text substitutions; a macro like
#define square(x) (x*x)
does not compute "x*x" and return a value; it *replaces* the text
"square(x)" with "(x*x)". If x is "z++", then the replacement text is
"(z++*z++)", which invokes undefined behavior. If x is "a+b", then
the replacement text is "(a+b*a+b)". By using all-uppercase for
macros, it makes it easier to see potential red flags like "SQUARE(x+
+)" or "SQUARE(x+y)".
> 2. My personal variable and function naming style is camel case, with variable
> names beginning with a lower case char and function names not. Is that
> acceptable, if not what is?
>
> EG:
> Variables: int numFiles = 0;
> Functions: int CountNumFilesInDir(char* path);
>
That's fine. Just be consistent.
> 3. Is there an accepted maximum line length? I've got a 24" monitor, if I reach
> 120 chars I start thinking this might not look great in someone else's editor.
>
Side scrolling is irritating. Just make sure you break lines up
sensibly.
> 4. Does anyone care where the pointer * is? I prefer keeping to next to the
> type, rather than next to the variable name.
>
> EG. I like: char* firstName; and not so much: char *firstName;
>
It's an accident of C lexical rules that you can write it either way.
The second form correctly reflects the language syntax (the '*'
operator is bound to the declarator, not the type specifier), and
tends to be preferred among C programmers. It also guards against
potential mistakes like
char* a, b; // b is a regular char
Declarations in C (and C++) reflect the type of an *expression*, not
an object. The type of the *expression* "*firstName" is char. The
idea is that the form of the declaration should closely match the form
of an expression that yields a value of that type. If you have an
array of pointers to int, and you wanted to access a specific int
value, the expression would be "x = *a[i];" The type of the
*expression* "*a[i]" is int, so the declaration of a is "int *a[N]".
C++ programmers prefer "char* firstName", because the type of the
*object* "firstName" is char*. Fine, but what about "char
lastName[20]"? The type of "lastName" is "20-element array of char",
but we can't write "char[20] lastName". Same thing for function
types. Same thing for pointers to arrays, pointers to functions,
etc.
> 5. On a slightly different note, I've been handling my error messages by using
> #define string constants in a header file. I saw some code which did this and it
> looked good to me. Is that standard practise, if not what is?
>
> EG. #define ErrorDirNotFound "The directory was not found."
>
> There are so many style guides out there, most of them say contradictory things
> at one point or another. What do the pros do?
>
I can't speak for anyone else, but I typically create a string table
and an enum to index it:
enum ErrorCodes {ErrDirNotFound, ErrInvalidPath, ...};
char ErrorStrings[] = {"Directory not found", "Path is invalid", ...};
It scales a little better than using #defines all over the place.
> Finally, before someone points this out... I know if I'm coding for myself, and
> not following somebody else's stylistic requirements, I can do whatever I want.
> However I'd like my code to be 'acceptable looking' to the wider UNIX C community.
>
> Thanks and regards, etc.
Stephen Sprunk
> Stephen Sprunk <ste...@sprunk.org> writes:
>> On 24 Feb 2010 12:35, Poster Matt wrote:
> [...]
>>> EG:
>>> Variables: int numFiles = 0;
>>
>>
>>> Functions: int CountNumFilesInDir(char* path);
>>
>> This is PascalCase.
>>
>> Mixing the two in the same project will drive adherents of _both_ styles
>> nuts. Pick one and stick to it; that way you'll only drive half of your
>> readers nuts.
>
> His convention apparently is to use camelCase for variables and
> PascalCase for functions. It's not necessarily a style I'd use, but
> it's not obviously horrible (and it's more or less the style I use
> at work).
Granted, it's not as bad as mixing the two within the same type of
thing, but it's still bad, IMHO.
I hate PascalCase; I can deal with it if _everything_ is cased that way,
but a lot of my functions and function calls would end up in camelCase
if I had to switch back and forth.
> As with most of these rules, conforming to existing code
> is far more important than any benefits of one style over another.
Of course; I said roughly the same thing at the top of my post. I've
just never seen a project that does it that way--or perhaps it was so
painful for me to read that I gave up, moved on, and repressed the memory.
>> (There's also this_type_of_identifier; the same logic applies, i.e.
>> don't mix that with either of the above. Never, never create some
>> God-awful hybrid with both underscores and uppercase letters...)
>
> Again, This_Type_Of_Identifier isn't obviously horrible. (I use it
> myself, though not in C.)
IMHO, that's also horrible. What I was thinking of was worse, though:
this_typeOfIdentifier. "Horrible" isn't strong enough for that.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
Poster Matt
>
> I'd have guessed Java, but as Rainer Weikusat points out in
> <87d3zuf...@fever.mssgmbh.com>, CamelCase and co. originate from
> much earlier. (Thanks for the interesting historical tidbit, Rainer!)
OP here...
I picked them up from a university lecturer of mine during a software
engineering course in the mid 1990's. The course required groups of 5 students
collaborating on a coding project, don't remember what language we used but
definitely not C or C++, possibly Java, but not sure.
The lecturer explained that in real world projects with a programming team, a
style guide would be the norm. So he imposed his own one on us. When free to
choose, I've been using my own variation of it ever since. It may have been
influenced by a book called Code Complete, but it's so long since I read it that
I can't recall exactly what I picked up from that and what from personal
experience and preference.
Poster Matt
>>
> Contradict each other, of course! Why did you ask?
Given the amount of contradictory advise I'm getting in this
thread I am beginning to wonder why myself. :)
BruceS
> BruceS wrote:
> > On Feb 25, 7:33 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > wrote:
> >> On Feb 25, 2:12 pm, ralt...@xs4all.nl (Richard Bos) wrote:
>
> >>> Yeah. Those Kernighan and Ritchie guys knew jack shit about C.
> >> As CS Lewis said, the first pot, which would prove its maker a genius
> >> if it were the first pot ever made, would prove him a dunce if it came
> >> after many millenia of pot-making.
>
> > That's a good one; I'll try to remember it.
> > FWIW, the K&R bit was intentional, to make the joke more obvious. Not
> > obvious enough for some, but apparently I either overestimated the
> > volume in the ng, or underestimated the mass. My bad.
>
> Is it not possible that you underestimated the gravity of the situation?
Oh no, the n-body problem, with n>20! I really *did* mess up.
Keith Thompson
[...]
> The all-caps convention makes it easier to distinguish preprocessor
> macros from other symbols. This can matter, especially when using
> function-like macros (macros that take arguments). Remember that
> macro expansions are simple text substitutions; a macro like
>
> #define square(x) (x*x)
>
> does not compute "x*x" and return a value; it *replaces* the text
> "square(x)" with "(x*x)". If x is "z++", then the replacement text is
> "(z++*z++)", which invokes undefined behavior. If x is "a+b", then
> the replacement text is "(a+b*a+b)". By using all-uppercase for
> macros, it makes it easier to see potential red flags like "SQUARE(x+
> +)" or "SQUARE(x+y)".
The side effect problem can't be solved (or at least can't be easily
solved) if you're using a macro, but the operator precedence problem
can.
#define SQUARE(x) ((x)*(x))
You need to parenthesize the entire definition *and* each reference to
the parameter(s).
BTW, here's my favorite example of preprocessor abuse:
#include <stdio.h>
#define SIX 1+5
#define NINE 8+1
int main(void)
{
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
Scott Lurndal
>On 24 Feb 2010 22:09:43 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>>
>> if (condition) {
>>
>> is preferred over
>>
>> if (condition)
>> {
>>
>> Makes it much more likely that a properly written function will fit
>> on a single page/screen.
>
>Hmmm...
>
>if (condition) { <-- one line
>
>if (condition) <-- one line
>{ <-- and another one, makes two lines
>
>Does that really make a BIG difference?
On a 24-line screen, you betcha.
scott
Scott Lurndal
Ken and Dennis started the trend, and all my employers (operating system vendors)
have followed it.
This fragment is from c00.c (the Unix V6 C compiler (note the obsolete =& operator!)):
/*
* Search the keyword table.
* Ignore initial "." to avoid member-of-structure
* problems.
*/
findkw()
{
register struct kwtab *kp;
register char *p1, *p2;
char *wp;
int firstc;
wp = symbuf;
firstc = *wp;
*wp =& 0177;
for (kp=kwtab; (p2 = kp->kwname); kp++) {
p1 = wp;
while (*p1 == *p2++)
if (*p1++ == '\0') {
cval = kp->kwval;
return(1);
}
}
*wp = firstc;
return(0);
}
scott
Scott Lurndal
>Seebs wrote:
>> On 2010-02-25, Richard Heathfield <r...@see.sig.invalid> wrote:
>>> In fairness to Scott, I think he just intended to describe his personal
>>> experience. In my own experience, Allman style (i.e. the latter of the
>>> two styles quoted above) is almost universal. I can't actually call to
>>> mind a single project where 1TBS was used - but there must have been at
>>> least one; my memory isn't what it... um... ah!... was.
>>
>> The two that come to mind are Linux and NetBSD. :)
>
>:-) Well, again I was referring only to my own experience. I haven't
>actually worked on the source base to those two particular OSen. (Or
>indeed any other mainstream OSen, come to that.)
Which, aside from a short digression at Verisign, is all that I've
worked on, since Unix V6.
scott
Scott Lurndal
Please take a look at the V6 C compiler (Dennis wrote it himself).
For example:
/*
* Write out a string, either in-line
* or in the string temp file labelled by
* lab.
*/
putstr(lab, amax)
{
register int c, max;
nchstr = 0;
max = amax;
if (lab) {
strflg++;
outcode("BNB", LABEL, lab, BDATA);
max = 10000;
} else
outcode("B", BDATA);
while ((c = mapch('"')) >= 0) {
if (nchstr < max) {
nchstr++;
outcode("1N", c & 0377);
}
}
if (nchstr < max) {
nchstr++;
outcode("10");
}
outcode("0");
strflg = 0;
}
Rainer Weikusat
> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>> Keith Thompson <ks...@mib.org> writes:
>>> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>>>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>>> [...]
>>>>> 4. Does anyone care where the pointer * is? I prefer keeping to next
>>>>> to the type, rather than next to the variable name.
>>>>>
>>>>> EG. I like: char* firstName; and not so much: char *firstName;
>>>>
>>>>
>>>> char a[];
>>>>
>>>> Pointers to functions
>>>>
>>>> char (*a)();
>>>>
>>>> and pointers
>>>>
>>>> char *a;
>>>
>>> Array types, structure types, union types, function types, and pointer
>>> types are all derived types (C99 6.2.5).
>>
>> Exercise for the reader: Which of the six types defined above are
>> irrelevant for this statement about 'declaration of derived types'
>> because they belong to a different syntactical class than the three
>> examples? Which type is irrelevant because it cannot directly appear
>> in a variable declaration? Which other class of types should appear
>> instead because they can?
>
> You said that "C knows about three kinds of derived types". In fact,
> there are six. I was disputing the accuracy of your statement, not
> its relevance.
Given that these three kinds of derived types exist, my statement was
accurate. I didn't claim that there weren't any other derived types, I
just didn't write about them because they were irrelvant for the
statement I intended to make (this is, of course, just the same kind
of pointless nitpicking).
[...]
>>> But it might be acceptable to special-case on some cases *with*
>>> an understanding of the C type system. I prefer "char *a;" myself,
>>> but there's a valid argument that "char* a;" makes it more obvious
>>> that's meant (that a is of type char*).
>>
>> A type 'char*' doesn't exist. A type named 'char' does, and assuming
>> that T names an existing type, an object can be declared as 'pointer
>> to a T' by using the syntax
>>
>> T *o;
>>
>> 'Pointerness' is an attribute of the object, not of the type. This is
>> also consistent with the original intention behind this syntax, namely
>> that 'declaration should resemble use'.
>
> Wrong. char* is a type. Specifically, it's a derived type and a
> pointer type. See C99 6.2.5, particularly paragraph 20.
T *o;
is a pointer declarator and it means that the type of o is 'pointer to
T', not 'T*' (6.7.5.1|1).
[...]
> (And for the record, I agree that "T *o;" is preferable to
> "T* o;"; I just don't agree that it's a huge deal.)
It's a pointless inconsistency.
Keith Thompson
> Keith Thompson <ks...@mib.org> writes:
>> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>>> Keith Thompson <ks...@mib.org> writes:
>>>> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>>>>> C knows about three kinds of derived types, arrays
>>>>>
>>>>> char a[];
>>>>>
>>>>> Pointers to functions
>>>>>
>>>>> char (*a)();
>>>>>
>>>>> and pointers
>>>>>
>>>>> char *a;
>>>>
>>>> Array types, structure types, union types, function types, and pointer
>>>> types are all derived types (C99 6.2.5).
>>>
>>> Exercise for the reader: Which of the six types defined above are
>>> irrelevant for this statement about 'declaration of derived types'
>>> because they belong to a different syntactical class than the three
>>> examples? Which type is irrelevant because it cannot directly appear
>>> in a variable declaration? Which other class of types should appear
>>> instead because they can?
>>
>> You said that "C knows about three kinds of derived types". In fact,
>> there are six. I was disputing the accuracy of your statement, not
>> its relevance.
>
> Given that these three kinds of derived types exist, my statement was
> accurate. I didn't claim that there weren't any other derived types, I
> just didn't write about them because they were irrelvant for the
> statement I intended to make (this is, of course, just the same kind
> of pointless nitpicking).
Ok. I read your statement as implying that C recognizes those three
kinds of derived types and no others. Thanks for the clarification.
[...]
>>> A type 'char*' doesn't exist. A type named 'char' does, and assuming
>>> that T names an existing type, an object can be declared as 'pointer
>>> to a T' by using the syntax
>>>
>>> T *o;
>>>
>>> 'Pointerness' is an attribute of the object, not of the type. This is
>>> also consistent with the original intention behind this syntax, namely
>>> that 'declaration should resemble use'.
>>
>> Wrong. char* is a type. Specifically, it's a derived type and a
>> pointer type. See C99 6.2.5, particularly paragraph 20.
>
> T *o;
>
> is a pointer declarator and it means that the type of o is 'pointer to
> T', not 'T*' (6.7.5.1|1).
So you agree that "pointer to char" is a type, right? The type
"pointer to char" is commonly referred, using C syntax, as "char*".
I see no problem with referring to it that way.
And if the point you were trying to make was the type often referred
to as "char*" is properly referred to as "pointer to char", that
wasn't at all clear to me from what you wrote.
> [...]
>
>> (And for the record, I agree that "T *o;" is preferable to
>> "T* o;"; I just don't agree that it's a huge deal.)
>
> It's a pointless inconsistency.
I don't agree that it's entirely pointless, but I'm not going to argue
the point.
Kelsey Bjarnason
> James Harris <james.h...@googlemail.com> writes:
>>On 24 Feb, 20:53, BruceS <bruce...@hotmail.com> wrote:
>>
>>...
>>
>>> I would like to add that, as long as you're trying to use good style,
>>> for God's sake don't use the wrong indentation style. =A0If you put
>>> your opening braces on the same line as your conditional, you'll just
>>> look like a fool in front of your friends and colleagues.
>>
>>Snobbish nonsense!
>>
>>
>>
> Indeed.
>
> if (condition) {
>
> is preferred over
>
> if (condition)
> {
Not by me, it ain't. :)
> Makes it much more likely that a properly written function will fit on a
> single page/screen.
And less likely to catch proper vs improper bracing and indentation, when
the braces don't line up with the indents.
> In 30 years of C programming, no employer or project has used the latter
> form.
This is one of those cases where there really are legitimate reasons for
each approach, with the deciding factor being preference.
My take on this has always been to standardize the format "checked in",
then use indent or some equivalent, on check in and check out, to convert
between the "checkin format" and the individual coder's preferred format.
Ben Pfaff
> My take on this has always been to standardize the format "checked in",
> then use indent or some equivalent, on check in and check out, to convert
> between the "checkin format" and the individual coder's preferred format.
I've heard of this approach, but I always assumed that it was a
joke. You really use it?
--
"Welcome to the wonderful world of undefined behavior, where the demons
are nasal and the DeathStation users are nervous." --Daniel Fox
Phred Phungus
$ gcc -D_GNU_SOURCE -Wall -Wextra k1.c -o out
$ ./out
6 * 9 = 42
$ cat k1.c
#include <stdio.h>
#define SIX 1+5
#define NINE 8+1
int main(void)
{
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}
// gcc -D_GNU_SOURCE -Wall -Wextra k1.c -o out
$
SIX * NINE equals 1 + 5 * 8 + 1
I save these nice little toy programs in my linuxlog.
--
fred
Kelsey Bjarnason
> Kelsey Bjarnason <kbjar...@gmail.com> writes:
>
>> My take on this has always been to standardize the format "checked in",
>> then use indent or some equivalent, on check in and check out, to
>> convert between the "checkin format" and the individual coder's
>> preferred format.
>
> I've heard of this approach, but I always assumed that it was a joke.
> You really use it?
I have, repeatedly, over the years.
The problem with _not_ doing it is that you tend to get a lot of checkins
where the "diff" is wildly out of sync with what actually got changed,
particularly if the coder's tools do things such as switching tabs to
spaces or re-organizing braces, etc, etc, etc, which many tools do.
By using indent or an equivalent on checkin, you ensure a standard format
going in, such that only "real" changes are recorded, and by using it on
checkout, you deliver to the coder whatever flavour he's happiest with.
Or, you can skip it on checkout and just let him use whatever tools he
likes, but I've found delivering to the developer something which he is
maximally comfortable with, right out of the gate, tends to produce
maximum productivity and minimum frustration.
'Course, some of that will depend on the repository tools, too. Some can
be set to ignore whitespace differences, or to auto-format to a defined
standard, etc, etc, etc. Some can't. It's easier just to do it
yourself, with indent or equivalent, as part of the check-in/check-out
procedure.
robert...@yahoo.com
> On Thu, 25 Feb 2010 19:48:06 -0800, Ben Pfaff wrote:
> > Kelsey Bjarnason <kbjarna...@gmail.com> writes:
>
> >> My take on this has always been to standardize the format "checked in",
> >> then use indent or some equivalent, on check in and check out, to
> >> convert between the "checkin format" and the individual coder's
> >> preferred format.
>
> > I've heard of this approach, but I always assumed that it was a joke.
> > You really use it?
>
> I have, repeatedly, over the years.
>
> The problem with _not_ doing it is that you tend to get a lot of checkins
> where the "diff" is wildly out of sync with what actually got changed,
> particularly if the coder's tools do things such as switching tabs to
> spaces or re-organizing braces, etc, etc, etc, which many tools do.
>
> By using indent or an equivalent on checkin, you ensure a standard format
> going in, such that only "real" changes are recorded, and by using it on
> checkout, you deliver to the coder whatever flavour he's happiest with.
>
> Or, you can skip it on checkout and just let him use whatever tools he
> likes, but I've found delivering to the developer something which he is
> maximally comfortable with, right out of the gate, tends to produce
> maximum productivity and minimum frustration.
A problem with that approach is that it will trash any special/careful
formatting that you might use to clarify a complex section of code.
While indent allows you to disable formatting for sections, that's not
an ideal solution in many ways.
On the flip side, some people can't be coerced into clean formatting,
or making an effort to follow the formatting already established for
the module their editing, no matter how much violence you threaten.
Or keeping "use tabs" turned off in their editors. At times that gets
bad enough that the easiest solution is to go ahead and run indent (or
the equivalent) and live with the damage.
But there's really no excuse - following a formatting style is not
that hard, even if it's not exactly the one you prefer. Frankly there
is almost no excuse for not follow the existing style when modifying a
program. Or following the shop standards when creating a new module.
Richard Heathfield
> Kelsey Bjarnason <kbjar...@gmail.com> writes:
>
>> My take on this has always been to standardize the format "checked in",
>> then use indent or some equivalent, on check in and check out, to convert
>> between the "checkin format" and the individual coder's preferred format.
>
> I've heard of this approach, but I always assumed that it was a
> joke.
Really? Why so?
> You really use it?
I can't speak for Kelsey, obviously, but I wouldn't dream of doubting
him. And I've used it in a couple of places. It works very well.
Nick Keighley
wrote:
> On Feb 25, 11:15 pm, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
> > On Thu, 25 Feb 2010 19:48:06 -0800, Ben Pfaff wrote:
> > > Kelsey Bjarnason <kbjarna...@gmail.com> writes:
> > >> My take on this has always been to standardize the format "checked in",
> > >> then use indent or some equivalent, on check in and check out, to
> > >> convert between the "checkin format" and the individual coder's
> > >> preferred format.
>
> > > I've heard of this approach, but I always assumed that it was a joke.
> > > You really use it?
I worked on a project where you couldn't check code in unless it had
been through indent with a specified set of flags. Well you *could*
but it got flagged somewhere. At first I used to indent to my style
(the indent style was a mix of tabs and spaces which I hated) edit and
indent to project style before check in. But it was such a PITA I just
accepted project style in the end. [cue twenty page rant by nilg about
the corporate castration of the programmer]
> > I have, repeatedly, over the years.
>
> > The problem with _not_ doing it is that you tend to get a lot of checkins
> > where the "diff" is wildly out of sync with what actually got changed,
I do a special layout change only checkin if the layout had gone
wildly astray.
> > particularly if the coder's tools do things such as switching tabs to
> > spaces or re-organizing braces, etc, etc, etc, which many tools do.
I think your tools are broken
> > By using indent or an equivalent on checkin, you ensure a standard format
> > going in, such that only "real" changes are recorded, and by using it on
> > checkout, you deliver to the coder whatever flavour he's happiest with.
>
> > Or, you can skip it on checkout and just let him use whatever tools he
> > likes, but I've found delivering to the developer something which he is
> > maximally comfortable with, right out of the gate, tends to produce
> > maximum productivity and minimum frustration.
>
> A problem with that approach is that it will trash any special/careful
> formatting that you might use to clarify a complex section of code.
> While indent allows you to disable formatting for sections, that's not
> an ideal solution in many ways.
>
> On the flip side, some people can't be coerced into clean formatting,
> or making an effort to follow the formatting already established for
> the module their editing, no matter how much violence you threaten.
on the project I was on they simple wouldn't be able to checkin the
code. If they did end-run around *that* they'd run into trouble at
build time.
> Or keeping "use tabs" turned off in their editors. At times that gets
> bad enough that the easiest solution is to go ahead and run indent (or
> the equivalent) and live with the damage.
>
> But there's really no excuse - following a formatting style is not
> that hard, even if it's not exactly the one you prefer. Frankly there
> is almost no excuse for not follow the existing style when modifying a
> program. Or following the shop standards when creating a new module.
apart from some truly hideous layout styles. One guy must have been
told that using blank lines would make his code clearer.
#include <stdio.h>
int main ( void )
{
int i = 99;
printf ( "%d\n", i );
return 0;
}
he never used more than one blank line
Nick Keighley
> BruceS wrote:
> > On Feb 25, 7:33 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > wrote:
> >> On Feb 25, 2:12 pm, ralt...@xs4all.nl (Richard Bos) wrote:
>
> >>> Yeah. Those Kernighan and Ritchie guys knew jack shit about C.
> >> As CS Lewis said, the first pot, which would prove its maker a genius
> >> if it were the first pot ever made, would prove him a dunce if it came
> >> after many millenia of pot-making.
>
> > That's a good one; I'll try to remember it.
> > FWIW, the K&R bit was intentional, to make the joke more obvious. Not
> > obvious enough for some, but apparently I either overestimated the
> > volume in the ng, or underestimated the mass. My bad.
>
> Is it not possible that you underestimated the gravity of the situation?
likely misjudged the metric of the manifold
Nick Keighley
> C++ programmers prefer "char* firstName", because the type of the
> *object* "firstName" is char*. Fine, but what about "char
> lastName[20]"? The type of "lastName" is "20-element array of char",
> but we can't write "char[20] lastName".
but no True C++ would use a C-style array!
Kelsey Bjarnason
On Fri, 26 Feb 2010 00:29:05 -0800, Nick Keighley wrote:
>> > particularly if the coder's tools do things such as switching tabs to
>> > spaces or re-organizing braces, etc, etc, etc, which many tools do.
>
> I think your tools are broken
Why?
I happen to feel most comfortable working in a specific manner. Tabs are
tabs, three columns wide. Braces belong on the next line, under the
"for" or whatever they're tied to. A blank separating various things
which should be separated, but only one, and not needlessly. Etc, etc,
etc.
It's my preferred style, using it keeps me focussed on the problem
instead of figuring out where the other guy's (to me) brain-dead style
has left the thrice-damned open brace, particularly if he's using the
likewise thrice-damned "spaces, not tabs" so popular with some folks but
which plays merry hob with any editor capable of actually handling tabs
(i.e. anything written in the last 20 years).
There are three approaches one can take to this:
1) Adopt the other guy's standard, no matter how brain dead it may be.
2) Force him (or them) to use your own, obviously superior style.
3) Allow each coder to use their own style, but enforce a consistent
style for the repository.
I go for three, if only because for some strange reason, other coders
don't seem to agree that my obviously superior formatting style should be
adopted as a universal convention for all C code everywhere.
Option 1 ain't even an option. Let *him* use that brain-dead style if he
likes, but if I have to use it, I'd sooner quit and go work for Microsoft.
</tongue_in_cheek>
Tim Streater
My preferred approach is to do like this:
function wiggy ()
{
if (cond)
{
dostuff;
}
else {
dootherstuff;
}
}
This has been my approach ever since I was writing BCPL in the 70s - it
has the braces lining up so that the matching can be seen easily.
--
Tim
"That the freedom of speech and debates or proceedings in Parliament
ought not to be impeached or questioned in any court or place out of
Parliament"
Bill of Rights 1689
Tim Streater
> [snips]
>
> On Fri, 26 Feb 2010 00:29:05 -0800, Nick Keighley wrote:
>
>>>> particularly if the coder's tools do things such as switching tabs to
>>>> spaces or re-organizing braces, etc, etc, etc, which many tools do.
>>
>> I think your tools are broken
>
> Why?
>
> I happen to feel most comfortable working in a specific manner. Tabs are
> tabs, three columns wide. Braces belong on the next line, under the
> "for" or whatever they're tied to. A blank separating various things
> which should be separated, but only one, and not needlessly. Etc, etc,
> etc.
>
> It's my preferred style, using it keeps me focussed on the problem
> instead of figuring out where the other guy's (to me) brain-dead style
> has left the thrice-damned open brace, particularly if he's using the
> likewise thrice-damned "spaces, not tabs" so popular with some folks but
> which plays merry hob with any editor capable of actually handling tabs
> (i.e. anything written in the last 20 years).
Trouble with tabs is, what is a tab? I use the tab key but my editor
(TextWrangler) just converts them to spaces. Why should spaces bother an
editor, anyway?
Tim Woodall
Anand Hariharan <mailto.anan...@gmail.com> wrote:
> On Feb 24, 4:09�pm, sc...@slp53.sl.home (Scott Lurndal) wrote:
>>
>> � �if (condition) {
>>
>> is preferred over
>>
>> � �if (condition)
>>
>> Makes it much more likely that a properly written function will fit on a single
>> page/screen.
>>
>>
>
>
> You've gotten some strong reactions to your not-seen-in-30-years
> comment above.
>
> FWIW I use the latter form myself. However, one good reason I got
> from an ex-colleague for using the first style was that if you are
> scrolling upward in source code, and get to the closing brace of a
> block, using the keyboard shortcut in your editor for jumping to the
> matching brace will get you to see the if (or while or for)
> condition. Otherwise, it will only scroll upward to a point where the
> opening brace is shown as the first line, and one has to go up one
> line more. To me, this is not a big inconvenience.
>
However, the converse is that when cursoring down the code you have to:
a) watch the RH edge of the code for the brace and watch for when the
cursor is on the same line but in column 1 - this is especially true if
you've just bounced to a '}' previously because, at least in vim, you
then lose the "end of line" behaviour of the cursor and it retains the
column position.
b) At least for vim you have to then do $ to get to the end of the line
before you hit the % to find the matching close brace.
if(x<0) {
}
Hitting % while in column 1 of the if line in vim bounces you between
the '(' and ')'
if(x<0)
{
}
Hitting % while in column 1 (or any column) of the line with '{' bounces
you to the '}'
c) Assuming the code is correctly indented - starting with your cursor
on the '{' and then moving downwards you will have read the entire block
when the cursor first stops on a '}' (Assuming your cursor isn't
following the end of the line)
d) For people who persist on using long lines, putting the '{' on a line
on its own will mean it is not off the edge of the screen and invisible
or wrapped onto the next line
Obviously, the major advantage to putting the '{' on the same line as
the conditional is that it reduces paper usage when typesetting and
hence why you will normally see it in books.
Tim.
--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.
Richard Heathfield
<snip>
> Trouble with tabs is, what is a tab?
A quick way of inserting exactly two spaces into the source.
Tim Streater
> Tim Streater wrote:
> <snip>
>
>> Trouble with tabs is, what is a tab?
>
> A quick way of inserting exactly two spaces into the source.
Since I don't know what tab setting you had when you handed me the code,
I think s/exactly two/a random number of/ applies here.
Richard Heathfield
> On 26/02/2010 14:51, Richard Heathfield wrote:
>> Tim Streater wrote:
>> <snip>
>>
>>> Trouble with tabs is, what is a tab?
>>
>> A quick way of inserting exactly two spaces into the source.
>
> Since I don't know what tab setting you had when you handed me the code,
It doesn't matter, since all you get is spaces. (Well, hopefully you get
some code in between the white spaces, too...)
> I think s/exactly two/a random number of/ applies here.
No, exactly two. Always. It's the One True Tab Size. And if you
disagree, obviously you're not a real Scotsman.
Rich Webb
<timst...@waitrose.com> wrote:
>On 26/02/2010 14:51, Richard Heathfield wrote:
>> Tim Streater wrote:
>> <snip>
>>
>>> Trouble with tabs is, what is a tab?
>>
>> A quick way of inserting exactly two spaces into the source.
>
>Since I don't know what tab setting you had when you handed me the code,
>I think s/exactly two/a random number of/ applies here.
[George Lucas missed a bet when he chose to make Star Wars instead of
Style Wars.]
In the context of C source files, the tab character (\t or \x09 or 0x09
or however expressed) should always advance the cursor position to the
next mod 8 column.
The tab *key* on the other hand, may be chosen by the user to insert a
tab character, or a fixed number of spaces, or a variable number of
spaces which advance the cursor to a preferred mod n column.
Hard tabs in code that presume other than "every eight" are just evil.
--
Rich Webb Norfolk, VA
Nick Keighley
> On Fri, 26 Feb 2010 15:12:02 +0000, Tim Streater
>
> >On 26/02/2010 14:51, Richard Heathfield wrote:
> >> Tim Streater wrote:
> >>> Trouble with tabs is, what is a tab?
>
> >> A quick way of inserting exactly two spaces into the source.
>
> >Since I don't know what tab setting you had when you handed me the code,
> >I think s/exactly two/a random number of/ applies here.
>
> [George Lucas missed a bet when he chose to make Star Wars instead of
> Style Wars.]
too violent to get a 15 certificate
> In the context of C source files, the tab character (\t or \x09 or 0x09
> or however expressed) should always advance the cursor position to the
> next mod 8 column.
yes but even *this* isn't fixed. It's configurable "on most editors
designed within the last twenty years". If there were any concensus on
this I might accept tab characters in my source code.
> The tab *key* on the other hand, may be chosen by the user to insert a
> tab character, or a fixed number of spaces, or a variable number of
> spaces which advance the cursor to a preferred mod n column.
>
> Hard tabs in code that presume other than "every eight" are just evil.
yes. But as I noted earlier I've worked on a project was it was
compulsory to use them.
Tim Streater
> Tim Streater wrote:
>> On 26/02/2010 14:51, Richard Heathfield wrote:
>>> Tim Streater wrote:
>>> <snip>
>>>
>>>> Trouble with tabs is, what is a tab?
>>>
>>> A quick way of inserting exactly two spaces into the source.
>>
>> Since I don't know what tab setting you had when you handed me the code,
>
> It doesn't matter, since all you get is spaces. (Well, hopefully you get
> some code in between the white spaces, too...)
>
>> I think s/exactly two/a random number of/ applies here.
>
> No, exactly two. Always. It's the One True Tab Size. And if you
> disagree, obviously you're not a real Scotsman.
<innocent look>
You mean they tend to cheesepare?
</innocent>
Ben Pfaff
> On Thu, 25 Feb 2010 19:48:06 -0800, Ben Pfaff wrote:
>
>> Kelsey Bjarnason <kbjar...@gmail.com> writes:
>>
>>> My take on this has always been to standardize the format "checked in",
>>> then use indent or some equivalent, on check in and check out, to
>>> convert between the "checkin format" and the individual coder's
>>> preferred format.
>>
>> I've heard of this approach, but I always assumed that it was a joke.
>> You really use it?
>
> I have, repeatedly, over the years.
>
> The problem with _not_ doing it is that you tend to get a lot of checkins
> where the "diff" is wildly out of sync with what actually got changed,
> particularly if the coder's tools do things such as switching tabs to
> spaces or re-organizing braces, etc, etc, etc, which many tools do.
I've never seen widespread problems with that. When I do, I see
folks deal with it by telling the coder in question not to screw
stuff up.
Do any open source or free software projects work this way? I am
familiar with many, and I've never seen anything like this.
(Doesn't it take *forever* to reformat a large source tree, by
the way? It took a few minutes here just to run "wc" on the .c
files in a Linux kernel tree, and I imagine that "indent" is
slower than "wc".)
> By using indent or an equivalent on checkin, you ensure a standard format
> going in, such that only "real" changes are recorded, and by using it on
> checkout, you deliver to the coder whatever flavour he's happiest with.
Doesn't it screw up any careful formatting, e.g. of comments?
And sometimes careful placement of white space can make the code
much easier to read.
--
"Some programming practices beg for errors;
this one is like calling an 800 number
and having errors delivered to your door."
--Steve McConnell
Ben Pfaff
> Ben Pfaff wrote:
>> Kelsey Bjarnason <kbjar...@gmail.com> writes:
>>
>>> My take on this has always been to standardize the format "checked
>>> in", then use indent or some equivalent, on check in and check out,
>>> to convert between the "checkin format" and the individual coder's
>>> preferred format.
>>
>> I've heard of this approach, but I always assumed that it was a
>> joke.
>
> Really? Why so?
Because I've looked at many, many software projects and worked on
several and I've never seen this approach actually used.
--
"Structure padding is the use of extraneous materials to
enhance the shape of a struct and make it more attractive to
members of the opposite struct. (See also "struct silicone.")"
--Eric Sosman
Tim Streater
But this is just it. How am I supposed to know *what* you presume. The
tab key with my editor inserts spaces to the next mod 5 column. But they
are spaces, so any recipient thereof doesn't have to worry about it. Its
tabs in code wot are evil.
Nick
> Stephen Sprunk <ste...@sprunk.org> writes:
>> On 24 Feb 2010 12:35, Poster Matt wrote:
> [...]
>>> EG:
>>> Variables: int numFiles = 0;
>>
>> This is camelCase.
>>
>>> Functions: int CountNumFilesInDir(char* path);
>>
>> This is PascalCase.
>>
>> Mixing the two in the same project will drive adherents of _both_ styles
>> nuts. Pick one and stick to it; that way you'll only drive half of your
>> readers nuts.
>
> His convention apparently is to use camelCase for variables and
> PascalCase for functions. It's not necessarily a style I'd use, but
> it's not obviously horrible (and it's more or less the style I use
> at work). As with most of these rules, conforming to existing code
> is far more important than any benefits of one style over another.
> I really dislike the brace placement of the code I work on, but
> mixing my own style into it would be far worse (and wouldn't survive
> a code review anyway).
>
>> (There's also this_type_of_identifier; the same logic applies, i.e.
>> don't mix that with either of the above. Never, never create some
>> God-awful hybrid with both underscores and uppercase letters...)
>
> Again, This_Type_Of_Identifier isn't obviously horrible. (I use it
> myself, though not in C.)
I confess to using lower_case_like_this for variables, and
Initial_Capitals like that for functions. It does help when you see
run_this() and know you don't have to go looking for the prototype.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Nick
> Seebs <usenet...@seebs.net> wrote:
>
>> On 2010-02-24, Poster Matt <postermatt@no_spam_for_me.org> wrote:
>> > 5. On a slightly different note, I've been handling my error messages by using
>> > #define string constants in a header file. I saw some code which did this and it
>> > looked good to me. Is that standard practise, if not what is?
>>
>> > EG. #define ErrorDirNotFound "The directory was not found."
>>
>> No. Look into gettext() if you need to do this, or just put them in
>> literally.
>
> gettext() is nice if you have it (it's POSIX, isn't it? Not ISO, anyway,
> but common), but putting the messages in literally only works if you
> don't reuse them. IME, _some_ error messages are used more than once, in
> which case a #define is nice.
I create an enum for errors, and a table of messages (by using something
like this):
ERCODE(err_signal,"A Signal was trapped")
ERCODE(err_internal,"Something went wrong internal to the interpreter")
ERCODE(err_failure,"An operating system function failed")
ERCODE(err_memory,"Ran out of memory") // keep this as the last of the prog kil
lers
ERCODE(err_unimp,"This is not yet implemented")
ERCODE(err_syntax,"Syntax error")
ERCODE(err_open,"Error with file")
ERCODE(err_mismatch,"Mismatched types")
ERCODE(err_killed,"Program told to stop")
ERCODE(err_locking,"Database locking failed")
ERCODE(err_cs,"Error reported by ClearSilver templating system")
and a bit of #define magic, you can create the enum and the table
indexed by it in one go.
Oh, and I've just realised that this is non-conforming code. I probably
better start my error code macro with a P or something.
Keith Thompson
> Tim Streater wrote:
> <snip>
>
>> Trouble with tabs is, what is a tab?
>
> A quick way of inserting exactly two spaces into the source.
The One True Tabstop Width is 8.
I have to deal with code that was modified by multiple different
people. Most of them use a tabstop width of 4, but some apparently
use 2, 8, or something else, resulting in code that's not properly
formatted regardless of my own tabstop setting.
Everything I check in has its tabs expanded to spaces. (I use
"expand -t 4" with manual cleanup where necessary.)
Richard Tobin
Keith Thompson <ks...@mib.org> wrote:
>Richard Heathfield <r...@see.sig.invalid> writes:
>>> Trouble with tabs is, what is a tab?
>> A quick way of inserting exactly two spaces into the source.
>The One True Tabstop Width is 8.
>
>I have to deal with code that was modified by multiple different
>people. Most of them use a tabstop width of 4, but some apparently
>use 2, 8, or something else, resulting in code that's not properly
>formatted regardless of my own tabstop setting.
I think Richard H was referring to the effect of the tab key in an
editor, rather than the display of a tab character.
For example, I have the tab key set to indent 4 spaces; if I do
that twice I get a tab character which then displays as 8 spaces.
>Everything I check in has its tabs expanded to spaces.
Now that the overhead is (and has long been) unimportant, that's
probably a good idea.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Jonathan de Boyne Pollard
>
> [...] when cursoring down the code [...]
>
The next step in this merry little dance, danced so many times before,
is to point out the existence of folding text editors. Well done for
bringing the editor wars into the thread, though. That will make it
even larger. Now all you need is some way to bring the operating system
and browser wars in, as well. Obviously the earlier mentions of NetBSD
didn't take.
How about this
"Well we all know what coding styles were used to write ReactOS and
Google Chrome. And just look at the results!"
? (-:
James Harris
> Richard Heathfield <r...@see.sig.invalid> writes:
> > Tim Streater wrote:
> > <snip>
>
> >> Trouble with tabs is, what is a tab?
>
> > A quick way of inserting exactly two spaces into the source.
>
> The One True Tabstop Width is 8.
>
> I have to deal with code that was modified by multiple different
> people. Most of them use a tabstop width of 4, but some apparently
> use 2, 8, or something else, resulting in code that's not properly
> formatted regardless of my own tabstop setting.
>
> Everything I check in has its tabs expanded to spaces. (I use
> "expand -t 4" with manual cleanup where necessary.)
For anything outside Unix or Linux others may find the following tabs
expander and compressor useful
http://codewiki.wikispaces.com/tabs.py
It allows arbitrary and/or repeating tab stop positions and obeys they
usual Unix pipe arrangements. Examples of use are included on the
page.
Although it doesn't require Unix be aware that it does need Python.
I've not tested it under Python 3.x but it works ok under Python 2.x.
James
pete
>
> Tim Streater wrote:
> <snip>
>
> > Trouble with tabs is, what is a tab?
>
> A quick way of inserting exactly two spaces into the source.
FOUR SPACES!!!
--
pete
Eric Sosman
> Tim Streater wrote:
> <snip>
>
>> Trouble with tabs is, what is a tab?
>
> A quick way of inserting exactly two spaces into the source.
The only actual study I ever read of (that's "read of," as
in "I didn't read it myself and can't cite it") found that the
best tab spacing was greater than two and less than four. Even
without further experiment, it's blatantly obvious that these
lower and upper bounds bracket the Best Possible Tab Width, to
wit, pi spaces. This is easily approximated by making the tab
key operate probabilistically, advancing to a three- or four-
space position with probabilities 0.142 and 0.858, respectively.
(If you need a more accurate approximation to the fractional
part of pi, your lines are too long.)
--
Eric Sosman
eso...@ieee-dot-org.invalid
Eric Sosman
> [...] pi spaces. This is easily approximated by making the tab
> key operate probabilistically, advancing to a three- or four-
> space position with probabilities 0.142 and 0.858, respectively.
You've heard of "fencepost errors?" This is a "newspost error."
--
Eric Sosman
eso...@ieee-dot-org.invalid
Richard Heathfield
> Richard Heathfield <r...@see.sig.invalid> writes:
>> Tim Streater wrote:
>> <snip>
>>
>>> Trouble with tabs is, what is a tab?
>> A quick way of inserting exactly two spaces into the source.
>
> The One True Tabstop Width is 8.
You, sirrah, are no Scotsman!
<snip>
Stephen Sprunk
> (Doesn't it take *forever* to reformat a large source tree, by
> the way? It took a few minutes here just to run "wc" on the .c
> files in a Linux kernel tree, and I imagine that "indent" is
> slower than "wc".)
Last time I checked, the vast majority of wc's runtime was opening,
reading, and closing files, i.e. the parts that make the disk's head
skip all over the place, not actually counting lines. indent does a
little bit more with the data than wc does, but on a tolerably fast
machine I suspect that the extra work would just fill in (a few of) the
CPU cycles wc wastes while waiting for the disk...
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
Stephen Sprunk
> On 26/02/2010 14:51, Richard Heathfield wrote:
>> Tim Streater wrote:
>>> Trouble with tabs is, what is a tab?
>>
>> A quick way of inserting exactly two spaces into the source.
>
> Since I don't know what tab setting you had when you handed me the code,
> I think s/exactly two/a random number of/ applies here.
That's a problem with _mixing tabs and spaces_, which is Evil(tm).
If you use a tab character (inserted by pressing the tab key) for each
level of indentation, each programmer can set the tab stops in his
editor however he wants and it will look correct for everyone.
(That introduces a new problem if you want to limit to 80 columns, but
that can be remedied by saying "80 columns with X-character tabs".)