«

Before I embark on a new long-term project I'd appreciate your advice on how to split up
long names. I would like to keep the standards for command names the same as that for
variable names. Looking at the examples below, which ones seem better?

Straight names
echoclient
lastcharoffset
helloworld

Internal underscores
echo_client
last_char_offset
hello_world

I could also use embedded hyphens as my minus sign must be surrounded by whitespace
(please suspend disbelief while looking at these. I know they will look unfamiliar!)
echo-client
last-char-offset
hello-world

Mixed case
EchoClient
LastCharOffset
HelloWorld

Initial lower case then mixed
echoClient
lastCharOffset
helloWorld

In some ways I like the mixed case versions using an inital capital, especially as I may
want to prefix some names with a code for an abstract data type, which, when present,
could begin with a lower case. Is this getting too Microsoft-ish? Is it getting to
Hungarian? Is Hungarian bad when used with abstract data types rather than inbuilt ones?

Advice on which is or is not thought to be acceptable would be much appreciated. Please
bear in mind that I intend these names for commands/instructions as well as variables and
types. Constants would be in all caps.

--
Thanks,
James

James Harris <no.email.please> scribbled the following:

> Before I embark on a new long-term project I'd appreciate your advice on how to split up
> long names. I would like to keep the standards for command names the same as that for
> variable names. Looking at the examples below, which ones seem better?

> I could also use embedded hyphens as my minus sign must be surrounded by whitespace
> (please suspend disbelief while looking at these. I know they will look unfamiliar!)
> echo-client
> last-char-offset
> hello-world

Since when was the hyphen a legal character in a C identifier?

--
/-- Joona Palaste () ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"How can we possibly use sex to get what we want? Sex IS what we want."
- Dr. Frasier Crane

James Harris a formulé la demande :
> Before I embark on a new long-term project I'd appreciate your advice on how
> to split up long names. I would like to keep the standards for command names
> the same as that for

There is not standard about that. It may have company rules you are
supposed to follow (or create)

> variable names. Looking at the examples below, which ones seem better?

What do you mean by 'command name' ? No such a thing like a 'command'
in C.

> Straight names
> echoclient
> lastcharoffset
> helloworld

Unreadable to me (and others, I guess).

> Internal underscores
> echo_client
> last_char_offset
> hello_world

Ok

> I could also use embedded hyphens as my minus sign must be surrounded by
> whitespace

No such a thing in C.

> Mixed case
> EchoClient
> LastCharOffset
> HelloWorld

Ok

> Initial lower case then mixed
> echoClient
> lastCharOffset
> helloWorld

Sounds ugly to me, but who cares...

> In some ways I like the mixed case versions using an inital capital,
> especially as I may want to prefix some names with a code for an abstract
> data type, which, when present, could begin with a lower case. Is this
> getting too Microsoft-ish? Is it getting to Hungarian? Is Hungarian bad when
> used with abstract data types rather than inbuilt ones?

Original Hugarian is good,

a_xxx : array
p_yyy : pointer
s_zzz : string
etc.


but Hungarian à-la-Microsoft (typed) is evil and hard to read and
maintain.

--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com

James Harris <no.email.please> wrote:

> Before I embark on a new long-term project I'd appreciate your advice
> on how to split up long names. I would like to keep the standards for
> command names the same as that for variable names. Looking at the
> examples below, which ones seem better?

Please fix your line lenghts to something of around 70 (I reformatted
the text to make things readable).

> Straight names
> echoclient
> lastcharoffset
> helloworld

> Internal underscores
> echo_client
> last_char_offset
> hello_world

I would much prefer the second since it's way easier to read and
typos are easier to recognize. Just compare

lastcharoffset <-> last_char_offset
lastcharofset <-> last_char_of_set

and it should become clear immediately why I feel that way.

> I could also use embedded hyphens as my minus sign must be surrounded
> by whitespace (please suspend disbelief while looking at these. I know
> they will look unfamiliar!)
> echo-client
> last-char-offset
> hello-world

Huh? Unless you do some automatic conversion of the source code before
you pass it to the compiler that won't do what you expect...

> Mixed case
> EchoClient
> LastCharOffset
> HelloWorld

> Initial lower case then mixed
> echoClient
> lastCharOffset
> helloWorld

> In some ways I like the mixed case versions using an inital capital,

Well, I still would prefer the version with underscores since they
seem still easier to read (you immediately see the subdivision in
words because we're trained to expect spaces between words) but
having the upper case at the start of words gives you at least a lot
more visual clues then without. What becomes a problem with the
use of upper case characters is when you want to code some extra
meaning into the use of upper/lower case, e.g. have global variables
always start with an upper case character but everything else in
lower case and upper case for all word starts for typedef'ed stuff
like in

Var_array <- a global variable
Var_Type <- a type with a typedef somewhere in the headers

> especially as I may want to prefix some names with a code for an
> abstract data type, which, when present, could begin with a lower
> case. Is this getting too Microsoft-ish? Is it getting to Hungarian?
> Is Hungarian bad when used with abstract data types rather than
> inbuilt ones?

Well, lots of people loath Hungarian notation (and I am admittedly
one of them) because

a) all that stuff at the start makes it harder to read since you
always have to scan for the real variable name, especially when
used without an intervening underscore and you end up with names
like 'rgbsyHash' or 'rgwDic' (as taken directly from an article

http://cm-solutions.com/cms/technica...convention.htm

by its inventor Simonyi, it shows rather nicely why not to use it,
the example code mostly looks to me as if it had been rot13'ed),

b) if you're that far away from the definition of a variable that
it gets tedious to look it up (and you can't remember it) then
your function probably has already become too long

c) or, if this is a variable that is defined somewhere else, it
should have a name that at least gives you a clue to what its
type is.

> Advice on which is or is not thought to be acceptable would be much
> appreciated. Please bear in mind that I intend these names for
> commands/instructions as well as variables and types. Constants would
> be in all caps.

I tend to write function names in lower case only - that it's a
function normally is obvious because of the parenthesis following
it.
Regards, Jens
--
\ Jens Thoms Toerring ___
\__________________________ http://www.toerring.de

James Harris wrote:

> Before I embark on a new long-term project I'd appreciate your advice on how to split up
> long names. I would like to keep the standards for command names the same as that for
> variable names. Looking at the examples below, which ones seem better?
>
> Straight names
> echoclient
> lastcharoffset
> helloworld

No, you've got to separate words somehow for readability.

> Internal underscores
> echo_client
> last_char_offset
> hello_world

OK, but obviously takes one more char than mixed case.

> I could also use embedded hyphens as my minus sign must be surrounded by whitespace
> (please suspend disbelief while looking at these. I know they will look unfamiliar!)
> echo-client
> last-char-offset
> hello-world

No, not legal C and worth avoiding in any language that would allow it.

> Mixed case
> EchoClient
> LastCharOffset
> HelloWorld

OK, but the assumption then is that your variables start with an
upper-case letter and, if you follow that rather than special-casing it,
then your one-char tmp counter names should be, say, "I" which looks
weird and probably invades your other naming conventions such as
reservaing all-upper-case for enum, macro, and type names.

> Initial lower case then mixed
> echoClient
> lastCharOffset
> helloWorld

I'd go with that.

> In some ways I like the mixed case versions using an inital capital, especially as I may
> want to prefix some names with a code for an abstract data type, which, when present,
> could begin with a lower case.

So if you start with lower-case then "helloWorld" would be "xHelloWorld"
- that seems fine. You could also introduce an underscore between the
code and the rest of the word if that's important.

Is this getting too Microsoft-ish? Is it getting to
> Hungarian? Is Hungarian bad when used with abstract data types rather than inbuilt ones?
>
> Advice on which is or is not thought to be acceptable would be much appreciated. Please
> bear in mind that I intend these names for commands/instructions as well as variables and
> types. Constants would be in all caps.

By commands/instructions, I assume you mean "functions" and the above
would be fine for those.

Ed.

> --
> Thanks,
> James
>
>

In other news, Ed Morton <> was quoted today as
saying:
> James Harris wrote:

> No, not legal C and worth avoiding in any language that would allow
> it.
>
>> Mixed case
>> EchoClient
>> LastCharOffset
>> HelloWorld
>
> OK, but the assumption then is that your variables start with an
> upper-case letter and, if you follow that rather than special-casing
> it, then your one-char tmp counter names should be, say, "I" which
> looks weird and probably invades your other naming conventions such as
> reservaing all-upper-case for enum, macro, and type names.

The answer to which might be to avoid one-char tmp counter names

>> Initial lower case then mixed
>> echoClient
>> lastCharOffset
>> helloWorld
>
> I'd go with that.
>

This is what I find myself using as it feels more natural than the others.

--
runtime

Be consistent and choose something readable.

thisisalongname() is not readable and I can't see many people would endorse
this way.

this_is_a_long_name() is fairly accepatble I feel. However at the moment I
use a style like this:


ModuleX_ThisIsALongName()

I use the uncapitalised method for local variables:

size_t line_count;

and sometimes I use an 'a' prefix for arguments, although I am not entirely
happy with this:

fn( aDest, aSrc, aLen )
{
}

It's not easy to say what is best, but I would avoid anything too
extravegant like hungarian notation, I prefer naming conventions to give
information about the semantects of an identifier rarther than it's type.
i.e. I use aParamater, rathar than saying iParamater ( meaning integer )
because then you might have to rename all your identifiers if they change
type.

"James Harris" <no.email.please> wrote in message
>
>
> Before I embark on a new long-term project I'd appreciate your advice on
> how to split up long names. I would like to keep the standards for command
> names the same as that for variable names. Looking at the examples below,
> which ones seem better?
>
You are not using C. However you should have very few variables in scope in
any structured programming language. Variables within a function can be
called anything meaningful (eg i for a nondescript counter, N for a count of
objects, x and y for co-ordinates, theta for an angle, ptr for a pointer,
ojprice for the price of orange juice etc). The few global variables you
need should be prefixed g_ and then called anything.

However you could have many hundreds of function identifiers. What I do is
name portable (in C, pure ANSI C ) functions in lowercase, whilst
platform-specific functions have Uppercase Initials.
Normally you won't have namespace clashes for your portable functions,
because you are developing them as a corpus. The name can be kept relatively
short. The exception is when you are doing many operations on a structure
(eg to get the salary of a programmer, and artist, and a manager). What you
do is prefix every function with the name of the structure you pass it, so
we have

programmer_salary()
artist_salary();
manager_salary();

You shouldn't need longer names, eg programmer_initial_salary is bad because
it rapidly gets unreadable. Try to think of a short identifier instead.

Platform-specific functions can multiply to huge numbers, particularly is
you are writing an interactive program, so initialise the first letter of
each word.

MoveMouseCursor()

etc.

The problem with both underscores and capitals is that they are not
pronounced. Most people remember words by sound, because that is the primary
way we use language. Thus mouse_wheel and mousewheel rapidly become
confused. So it is important to stick to some consistent convention.

hungarian notation might be somthing you can look into but I dont'
think you will read all that. It really is pointless(IMO) I use
the opengl way of declaring functions ex:

glTexSubImage();

although I have programmed in GTK and they use the _ method

gtk_radio_button_new_with_label_from_widget

the latter method really starts to hurt your wrist if you are writing
a long program and use the correct typing method(Too must reaching +
it throws off the rythm of typing(slows you down)). I would recommend
the former Faster and one less keystroke

"James Harris" <no.email.please> wrote in message
news:40f91832$0$7803$...
>
> Before I embark on a new long-term project I'd appreciate your advice on
> how to split up long names. I would like to keep the standards for
> command names the same as that for variable names. Looking at the
> examples below, which ones seem better?

Which style you use is a matter of personal preference, as long as you pick
a single style and stick with it.

> Initial lower case then mixed
> echoClient
> lastCharOffset
> helloWorld

This is what I use, but the initial-caps style and underscored (not
hyphenated) style are both common as well.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov