From: William Hughes on
On Feb 24, 2:35 pm, Poster Matt <postermatt(a)no_spam_for_me.org> wrote:


> 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






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

From: Ersek, Laszlo on
In article <slrnhob00o.fh7.usenet-nospam(a)guild.seebs.net>, Seebs <usenet-nospam(a)seebs.net> writes:
> On 2010-02-24, Poster Matt <postermatt(a)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
<87d3zuflhs.fsf(a)fever.mssgmbh.com>, CamelCase and co. originate from
much earlier. (Thanks for the interesting historical tidbit, Rainer!)

Cheers,
lacos
From: Ersek, Laszlo on
In article <7f8b94fc-a78e-4c64-becf-f70a3843de08(a)o3g2000yqb.googlegroups.com>, James Harris <james.harris.1(a)googlemail.com> writes:
> On 24 Feb, 20:53, BruceS <bruce...(a)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. 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!

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
From: Stephen Sprunk on
On 24 Feb 2010 12:35, Poster Matt wrote:
> 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
From: William Hughes on
On Feb 24, 4:53 pm, BruceS <bruce...(a)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.  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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Prev: integer
Next: shared memory question