«

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'.


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.

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.
>
> 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.

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:
>
> > 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.

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

On 24 Feb, 18:35, 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.

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

On February 24, 2010 13:35, in comp.lang.c, 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.
>
> 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. ------

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".

> 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-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Wed, 24 Feb 2010 11:10:21 -0800 (PST), Julienne Walker
<> 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

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;
>
> > 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.

On 2/24/2010 1:35 PM, Poster Matt 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'.

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
lid

Poster Matt <postermatt@no_spam_for_me.org> writes:
> 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.
TheReasonThatTextsAreNotWrittenLikeThisIsBecauseRe adibiltyIsCrappyThen.
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.