Q: programming style -- uppercase vs. lowercase

[Bob_Bottemiller1]

Hello QNX World,

(I did a mental coin toss about where to post this question –
applications and .devtools lost.)

I would appreciate any pointers to books, online articles or other
references which discuss function and variable naming. I’m talking
about the various stylistic forms and use of upper and lower case for
readability (excluding the so-called Hungarian notation developed at
Microsoft).

I realize this ranks even lower than bracket/brace placement in the
trivia category. But I find myself thoughtlessly changing styles from
day to day like:

1: void mybigfatfunction(int varone, long vartwo);

2: void my_big_fat_functtion(int var_one, long var_two);

3: void MyBigFatFunction(int varOne, long varTwo);

4: void MyBigFatFunction(int VarOne, long VarTwo);

I’m thinking #2 is more readable than #1 but adds a lot of underscores
(so what?). #4 is very readable but #3 makes a style statement about
variables versus functions by capitalizing the first letter of the
latter.

Some (many) years ago there was a book on programming styles patterned
after the classic “Elements of Style” for English usage. Is there a
more modern version?

Thanks,
Bob Bottemiller
Stein.DSI/Redmond, WA USA

[Mario_Charest1]

“Bob Bottemiller” <bob.bottemiller@fmcti.com> wrote in message
news:3bb9f063.5220695@inn.qnx.com…

Hello QNX World,

(I did a mental coin toss about where to post this question –
applications and .devtools lost.)

I would appreciate any pointers to books, online articles or other
references which discuss function and variable naming. I’m talking
about the various stylistic forms and use of upper and lower case for
readability (excluding the so-called Hungarian notation developed at
Microsoft).

I realize this ranks even lower than bracket/brace placement in the
trivia category. But I find myself thoughtlessly changing styles from
day to day like:

1: void mybigfatfunction(int varone, long vartwo);

2: void my_big_fat_functtion(int var_one, long var_two);

3: void MyBigFatFunction(int varOne, long varTwo);

4: void MyBigFatFunction(int VarOne, long VarTwo);

I’m thinking #2 is more readable than #1 but adds a lot of underscores
(so what?). #4 is very readable but #3 makes a style statement about
variables versus functions by capitalizing the first letter of the
latter.

Oh oh I smell a long thread

My suggestion is try all four for 2 weeks each. Then after 8 weeks
pick the one you like.

IMHO it all depends on too many factors, your own priority and preferences.
Readability? Typing speed? Hardisk space other people around
you?

Personnaly I’ve gone through the #2, #3, #4 cycle over the last 10 years.
I won’t tell you which one I’m using now But what I know is
I will probably change again some day.

Even QNX API isn’t consistant, they use different style.

Some (many) years ago there was a book on programming styles patterned
after the classic “Elements of Style” for English usage. Is there a
more modern version?

Thanks,
Bob Bottemiller
Stein.DSI/Redmond, WA USA

[Rennie_Allen2]

I use #2 for C code, and #3 for C++ code (for function naming). I
always use lowercase for member variables, and arguments.

There is no “correct” style (other than the fact that hungarian notation
is just plain wrong and completely evil).

-----Original Message-----
From: Mario Charest [mailto:mcharest@clipzinformatic.com]
Posted At: Tuesday, October 02, 2001 10:38 AM
Posted To: advocacy
Conversation: programming style – uppercase vs. lowercase
Subject: Re: programming style – uppercase vs. lowercase



“Bob Bottemiller” <bob.bottemiller@fmcti.com> wrote in message
news:3bb9f063.5220695@inn.qnx.com…

Hello QNX World,

(I did a mental coin toss about where to post this question –
applications and .devtools lost.)

I would appreciate any pointers to books, online articles or other
references which discuss function and variable naming. I’m talking
about the various stylistic forms and use of upper and lower case for
readability (excluding the so-called Hungarian notation developed at
Microsoft).

I realize this ranks even lower than bracket/brace placement in the
trivia category. But I find myself thoughtlessly changing styles from
day to day like:

1: void mybigfatfunction(int varone, long vartwo);

2: void my_big_fat_functtion(int var_one, long var_two);

3: void MyBigFatFunction(int varOne, long varTwo);

4: void MyBigFatFunction(int VarOne, long VarTwo);

I’m thinking #2 is more readable than #1 but adds a lot of underscores
(so what?). #4 is very readable but #3 makes a style statement about
variables versus functions by capitalizing the first letter of the
latter.

Oh oh I smell a long thread

My suggestion is try all four for 2 weeks each. Then after 8 weeks
pick the one you like.

IMHO it all depends on too many factors, your own priority and
preferences.
Readability? Typing speed? Hardisk space other people around
you?

Personnaly I’ve gone through the #2, #3, #4 cycle over the last 10
years.
I won’t tell you which one I’m using now But what I know is
I will probably change again some day.

Even QNX API isn’t consistant, they use different style.

Some (many) years ago there was a book on programming styles patterned
after the classic “Elements of Style” for English usage. Is there a
more modern version?

Thanks,
Bob Bottemiller
Stein.DSI/Redmond, WA USA

[Xiaodan_Tang1]

Bob Bottemiller <bob.bottemiller@fmcti.com> wrote:

Hello QNX World,

(I did a mental coin toss about where to post this question –
applications and .devtools lost.)

I would appreciate any pointers to books, online articles or other
references which discuss function and variable naming. I’m talking
about the various stylistic forms and use of upper and lower case for
readability (excluding the so-called Hungarian notation developed at
Microsoft).

I realize this ranks even lower than bracket/brace placement in the
trivia category. But I find myself thoughtlessly changing styles from
day to day like:

1: void mybigfatfunction(int varone, long vartwo);

2: void my_big_fat_functtion(int var_one, long var_two);

3: void MyBigFatFunction(int varOne, long varTwo);

4: void MyBigFatFunction(int VarOne, long VarTwo);

I have seen 5 from some company selling source code.

5: void myBigFatFunction(struct MyVar varOne, long varTwo);

All variables are start from low case, and all private type start
from capital case.

-xtang

I’m thinking #2 is more readable than #1 but adds a lot of underscores
(so what?). #4 is very readable but #3 makes a style statement about
variables versus functions by capitalizing the first letter of the
latter.

Some (many) years ago there was a book on programming styles patterned
after the classic “Elements of Style” for English usage. Is there a
more modern version?

Thanks,
Bob Bottemiller
Stein.DSI/Redmond, WA USA

[Bill_Caroselli_Q-TPS]

“Mario Charest” <mcharest@clipzinformatic.com> wrote in message
news:9pctro$3s$1@inn.qnx.com…

Oh oh I smell a long thread >

Oh yeah!

Here’s another wrinckle. I use leading Caps for global data and lowercase
for locals.

I think that the single most important rule is, after you’ve experimented a
little bit, pick one and be consistant.

[Bill_Caroselli_Q-TPS]

“Rennie Allen” <RAllen@csical.com> wrote in message
news:64F00D816A85D51198390050046F80C9F488@exchangecal.hq.csical.com…

There is no “correct” style (other than the fact that hungarian notation
is just plain wrong and completely evil).

Why not just adpot full C++ name mangeling as ‘you’ name your variables,
then let the C++ compiler remangle them. Kind of like mangeled squared.

[Marty_Doane1]

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:9pd9hj$1mu$1@nntp.qnx.com…

Bob Bottemiller <> bob.bottemiller@fmcti.com> > wrote:
Hello QNX World,

(I did a mental coin toss about where to post this question –
applications and .devtools lost.)

I would appreciate any pointers to books, online articles or other
references which discuss function and variable naming. I’m talking
about the various stylistic forms and use of upper and lower case for
readability (excluding the so-called Hungarian notation developed at
Microsoft).

I realize this ranks even lower than bracket/brace placement in the
trivia category. But I find myself thoughtlessly changing styles from
day to day like:

1: void mybigfatfunction(int varone, long vartwo);

2: void my_big_fat_functtion(int var_one, long var_two);

3: void MyBigFatFunction(int varOne, long varTwo);

4: void MyBigFatFunction(int VarOne, long VarTwo);

I have seen 5 from some company selling source code.

5: void myBigFatFunction(struct MyVar varOne, long varTwo);

All variables are start from low case, and all private type start
from capital case. >

6: void myBigFatFunction(int aVarOne, long aVarTwo);

All classnames are mixed case nouns beginning with a capital.
All operations (functions) are mixed case verbs beginning with a lower case.
All variables include a prefix, followed by a mixed case name:
a = argument
l = local variable
m = C++ member variable
c = C++ class variable
g = global variable
s = static variable

Marty

[Mario_Charest1]

“Marty Doane” <marty.doane@rapistan.com> wrote in message
news:9pev1c$75o$1@inn.qnx.com…

“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:9pd9hj$1mu$> 1@nntp.qnx.com> …
Bob Bottemiller <> bob.bottemiller@fmcti.com> > wrote:
Hello QNX World,

(I did a mental coin toss about where to post this question –
applications and .devtools lost.)

I would appreciate any pointers to books, online articles or other
references which discuss function and variable naming. I’m talking
about the various stylistic forms and use of upper and lower case for
readability (excluding the so-called Hungarian notation developed at
Microsoft).

I realize this ranks even lower than bracket/brace placement in the
trivia category. But I find myself thoughtlessly changing styles from
day to day like:

1: void mybigfatfunction(int varone, long vartwo);

2: void my_big_fat_functtion(int var_one, long var_two);

3: void MyBigFatFunction(int varOne, long varTwo);

4: void MyBigFatFunction(int VarOne, long VarTwo);

I have seen 5 from some company selling source code.

5: void myBigFatFunction(struct MyVar varOne, long varTwo);

All variables are start from low case, and all private type start
from capital case. >

6: void myBigFatFunction(int aVarOne, long aVarTwo);

I’ve seen

void My_Big_Fat_Function( int Var_One, long Var_Two);

All classnames are mixed case nouns beginning with a capital.
All operations (functions) are mixed case verbs beginning with a lower
case.
All variables include a prefix, followed by a mixed case name:
a = argument
l = local variable
m = C++ member variable
c = C++ class variable
g = global variable
s = static variable

Marty

[Kris_Eric_Warkentin]

Kernighan and Plauger wrote a book “The Elements of Programming Style”
but it’s out of print now. I think that Kernighan and Pike’s book
“The Practice of Programming” has a pretty good style section. It’s
also a generally excellent book…

I personally use all lower case with underscores for C variables and
functions, all uppercase with underscores for constants and defines.
Some people like the meta-information of hungarian type variable names
and I believe Kernighan suggests it. I sometimes use a _p to
designate a pointer and almost always use a _t for typedefs.

For Java/C++/other oops, I use Sun’s variable naming conventions
(classes: MyClass, instances: myInstance, constants:ALL_CAPS)

cheers,


Bob Bottemiller <bob.bottemiller@fmcti.com> wrote:

Hello QNX World,

(I did a mental coin toss about where to post this question –
applications and .devtools lost.)

I would appreciate any pointers to books, online articles or other
references which discuss function and variable naming. I’m talking
about the various stylistic forms and use of upper and lower case for
readability (excluding the so-called Hungarian notation developed at
Microsoft).

I realize this ranks even lower than bracket/brace placement in the
trivia category. But I find myself thoughtlessly changing styles from
day to day like:

1: void mybigfatfunction(int varone, long vartwo);

2: void my_big_fat_functtion(int var_one, long var_two);

3: void MyBigFatFunction(int varOne, long varTwo);

4: void MyBigFatFunction(int VarOne, long VarTwo);

I’m thinking #2 is more readable than #1 but adds a lot of underscores
(so what?). #4 is very readable but #3 makes a style statement about
variables versus functions by capitalizing the first letter of the
latter.

Some (many) years ago there was a book on programming styles patterned
after the classic “Elements of Style” for English usage. Is there a
more modern version?

Thanks,
Bob Bottemiller
Stein.DSI/Redmond, WA USA

–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
“I love deadlines. I like the whooshing sound they make as they fly by.”
– Douglas Adams

[Mitchell_Schoenbrun]

Previously, Rennie Allen wrote in qdn.public.qnxrtp.advocacy:

3: void MyBigFatFunction(int varOne, long varTwo);

Just my 2 cents about this style technique. It does add reability,
and it quadruples the typo (capitalization) errors I end up with.

Mitchell Schoenbrun --------- maschoen@pobox.com

[Mitchell_Schoenbrun]

Well here’s my 25cent point. Obviously style is important,
but I’m of the opinion that the type of style being
discussed is a case of overload. Take for example that
technique of adding prefixes to every variable to tell you
exactly what it is, ie.

iCounter integer
piCounter pointer to integer

Well the supposed nice feature here is that you can look at
the variable name and immediately know what type of variable
it is. The problem is that there is no compiler errors
generated by inconsistencies, so if you decide based on the
name, showing confidence in all previous programmers who’ve
touched the code, you could be wrong. This opens you up to
precisely the type of bug that you were trying to avoid,
only now you are not as on guard against it.

I’m not completely against this idea. I like i,j,k… as
simple counting integers, and adding a small ‘p’ preix to
indicate a pointer. I just think that one can go overboard.


Mitchell Schoenbrun --------- maschoen@pobox.com

[Wojtek_Lerch1]

Kris Eric Warkentin <kewarken@qnx.com> wrote:

Kernighan and Plauger wrote a book “The Elements of Programming Style”
but it’s out of print now. I think that Kernighan and Pike’s book
“The Practice of Programming” has a pretty good style section. It’s
also a generally excellent book…

I personally use all lower case with underscores for C variables and
functions, all uppercase with underscores for constants and defines.

Personally, I like the idea of using different conventions to let the
reader easily distinguish between external symbols and locals/statics
(in C++, also between public and private stuff). This lets you easily
tell whether a function can be aware of details that are only visible
from the same source file.

I think it’s a good idea to also differentiate by the length of
identifiers: external names should be long and meaningful, local
variables can have simple names like “i” or “ptr”, and statics fit
somewhere in between. Since mixed case takes less space than
underscores, it makes sense to use mixed case for externs, and
underscores for locals and statics.

I don’t see much point in using different styles for functions and
variables – C makes it easy enough to guess from the context whether a
name refers to a variable or a function. If you want to make it clear
that you’re calling a function through a pointer, write “(*fptr)()”
rather than “fptr()”.

Some people like the meta-information of hungarian type variable names
and I believe Kernighan suggests it. I sometimes use a _p to
designate a pointer and almost always use a _t for typedefs.

That’s not portable. Names with trailing “_t” are “reserved for
implementation” by POSIX. I know that inside this building, we
control what our implementation defines, but if you’re writing an
application that you want to easily port to other OSes (or if you aren’t
a QNX employee), it’s good to adopt some other convention for your
typedefs.

–
Wojtek Lerch QNX Software Systems Ltd.

[Wojtek_Lerch1]

Mitchell Schoenbrun <maschoen@pobox.com> wrote:

Well here’s my 25cent point. Obviously style is important,
but I’m of the opinion that the type of style being
discussed is a case of overload. Take for example that
technique of adding prefixes to every variable to tell you
exactly what it is, ie.

iCounter integer
piCounter pointer to integer

Well the supposed nice feature here is that you can look at
the variable name and immediately know what type of variable
it is. The problem is that there is no compiler errors
generated by inconsistencies, so if you decide based on the
name, showing confidence in all previous programmers who’ve
touched the code, you could be wrong. This opens you up to
precisely the type of bug that you were trying to avoid,
only now you are not as on guard against it.

There’s more.

Quite often, especially in portable code, it’s not really interesting to
know whether a variable is an “int” or a “long”, because what’s really
meaningful is that it’s a “size_t”, “time_t”, “pid_t”, “uid_t”, “off_t”,
or some user-defined typedef whose real type is buried in a maze of #ifs
somewhere in a header. The Hungarian convention doesn’t work that well
with abstract types like those, does it…

Even with simple pointers to a structure, you usually can quickly figure
out from the context that a variable points to a structure (for
instance, when there’s a “->” operator next to it). The difficult part
is to guess what kind of a structure it points to – and again, the
Hungarian notation doesn’t help you there…

–
Wojtek Lerch QNX Software Systems Ltd.

[Bob_Bottemiller1]

Thanks to all who replied.
I did a cut-and-paste of the comments aimed directly at the style
issue for circulation in my software group. I insert it below as a
chronological summary for anyone seeing this thread late. I have not
tried to summarize the more philosophical statements which can be read
in their original form.

Bob Bottemiller <bob.bottemiller@fmcti.com> wrote:

I realize this ranks even lower than bracket/brace placement in the
trivia category. But I find myself thoughtlessly changing styles from
day to day like:
1: void mybigfatfunction(int varone, long vartwo);
2: void my_big_fat_function(int var_one, long var_two);
3: void MyBigFatFunction(int varOne, long varTwo);
4: void MyBigFatFunction(int VarOne, long VarTwo);

“Xiaodan Tang” <xtang@qnx.com> wrote in message

I have seen 5 from some company selling source code.
5: void myBigFatFunction(struct MyVar varOne, long varTwo);
All variables are start from low case, and all private type start
from capital case.

“Marty Doane” <marty.doane@rapistan.com> wrote in message

6: void myBigFatFunction(int aVarOne, long aVarTwo);
All classnames are mixed case nouns beginning with a capital.
All operations (functions) are mixed case verbs beginning with a lower
case.
All variables include a prefix, followed by a mixed case name:
a = argument
l = local variable
m = C++ member variable
c = C++ class variable
g = global variable
s = static variable

From: “Mario Charest” <mcharest@clipzinformatic.com>

I’ve seen
void My_Big_Fat_Function( int Var_One, long Var_Two);
[This would be example 7 - Bob B.]

From: Kris Eric Warkentin <kewarken@qnx.com>

Kernighan and Plauger wrote a book “The Elements of Programming Style”
but it’s out of print now. I think that Kernighan and Pike’s book
“The Practice of Programming” has a pretty good style section. It’s
also a generally excellent book…
I personally use all lower case with underscores for C variables and
functions, all uppercase with underscores for constants and defines.
Some people like the meta-information of hungarian type variable names
and I believe Kernighan suggests it. I sometimes use a _p to
designate a pointer and almost always use a _t for typedefs.
For Java/C++/other oops, I use Sun’s variable naming conventions
(classes: MyClass, instances: myInstance, constants:ALL_CAPS)
[Wojtek Lerch says trailing _t is “reserved for implentation” by POSIX

• Bob B.]

From: Mario Charest [mailto:mcharest@clipzinformatic.com]

My suggestion is try all four for 2 weeks each. Then after 8 weeks
pick the one you like.
IMHO it all depends on too many factors, your own priority and
preferences.
Readability? Typing speed? Hardisk space other people around
you?
Personnaly I’ve gone through the #2, #3, #4 cycle over the last 10
years.
I won’t tell you which one I’m using now But what I know is I
will probably change again some day.
Even QNX API isn’t consistant, they use different style.


From: Rennie Allen <RAllen@csical.com>

I use #2 for C code, and #3 for C++ code (for function naming). I
always use lowercase for member variables, and arguments.
There is no “correct” style (other than the fact that hungarian
notation
is just plain wrong and completely evil).

From: “Bill Caroselli (Q-TPS)” <qtps@earthlink.net>

Here’s another wrinckle. I use leading Caps for global data and
lowercase for locals.
I think that the single most important rule is, after you’ve
experimented a little bit, pick one and be consistant.


Bob Bottemiller
Stein.DSI/Redmond, WA USA

[ian_zagorskih2]

“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:9pfq73$jj2$1@nntp.qnx.com…

There’s more.

Quite often, especially in portable code, it’s not really interesting to
know whether a variable is an “int” or a “long”, because what’s really
meaningful is that it’s a “size_t”, “time_t”, “pid_t”, “uid_t”, “off_t”,
or some user-defined typedef whose real type is buried in a maze of #ifs
somewhere in a header. The Hungarian convention doesn’t work that well
with abstract types like those, does it…

Even with simple pointers to a structure, you usually can quickly figure
out from the context that a variable points to a structure (for
instance, when there’s a “->” operator next to it). The difficult part
is to guess what kind of a structure it points to – and again, the
Hungarian notation doesn’t help you there…

Even more, when you use some third-party library that follows Hungarian
notation, you’r risking to find in the next releast some really
“unsignificant improvement”. When authors just change some variable or
structure field type in the sake of scaleability. For example from short to
long. And [in order to be logocal] name from “sField” to “lField” or alike.
You see the approaching nightmare if you already have beed using this
“little but very significant” sField in hundreds of your source files, right
? On the other hand if there wern’t used Hungarian notation you would
have just to recompile your code…

–
Wojtek Lerch QNX Software Systems Ltd.

// wbr

[Kirk_Bailey]

ian zagorskih wrote:

Even more, when you use some third-party library that follows Hungarian
notation, you’r risking to find in the next releast some really
“unsignificant improvement”. When authors just change some variable or
structure field type in the sake of scaleability. For example from short to
long. And [in order to be logocal] name from “sField” to “lField” or alike.
You see the approaching nightmare if you already have beed using this
“little but very significant” sField in hundreds of your source files, right
? > > On the other hand if there wern’t used Hungarian notation you would
have just to recompile your code…

Exactly. I have always hated Hungarian notation with a passion.
I think it is a direct attack on “information hiding” by forcing
the source to know and care about a variable’s type whether it
really needs to or not. It creates unnecessary coupling, as you
point out. By doing so, it also encourages maintenance programmers
to not change the name if the type changes (due to a desire to
minimize changes). Then you end up with totally incorrect names!

–
Kirk Bailey

[Mitchell_Schoenbrun]

Previously, Wojtek Lerch wrote in qdn.public.qnxrtp.advocacy:

Quite often, especially in portable code, it’s not really interesting to
know whether a variable is an “int” or a “long”, because what’s really
meaningful is that it’s a “size_t”, “time_t”, “pid_t”, “uid_t”, “off_t”,
or some user-defined typedef whose real type is buried in a maze of #ifs
somewhere in a header. The Hungarian convention doesn’t work that well
with abstract types like those, does it…

A good point which brings up another. I find that code often has
no typedefs, which is fine with me, or they are overused. There’s
an excellent place for typedefs in good readable code, but when
overused it puts a great strain on debugging. As you point out,
you have to sift through layers of typedefs, often found in separate
header files, sometimes all over the system. An example of
too much of a good thing.

\

Mitchell Schoenbrun --------- maschoen@pobox.com

[David_Alessio]

Some people like the meta-information of hungarian type variable names
and I believe Kernighan suggests it. I sometimes use a _p to
designate a pointer and almost always use a _t for typedefs.

That’s not portable. Names with trailing “_t” are “reserved for
implementation” by POSIX. I know that inside this building, we
control what our implementation defines, but if you’re writing an
application that you want to easily port to other OSes (or if you aren’t
a QNX employee), it’s good to adopt some other convention for your
typedefs.

Hmmm, I got used to this typedef name_t convention (didn’t know POSIX
claimed *_t). Any suggestions for alternatives?

-david

[Mario_Charest1]

“David Alessio” <david.alessio@hsa.hitachi.com> wrote in message
news:3BCC825A.1162EBB4@hsa.hitachi.com…

Some people like the meta-information of hungarian type variable names
and I believe Kernighan suggests it. I sometimes use a _p to
designate a pointer and almost always use a _t for typedefs.

That’s not portable. Names with trailing “_t” are “reserved for
implementation” by POSIX. I know that inside this building, we
control what our implementation defines, but if you’re writing an
application that you want to easily port to other OSes (or if you aren’t
a QNX employee), it’s good to adopt some other convention for your
typedefs.


Hmmm, I got used to this typedef name_t convention (didn’t know POSIX
claimed *_t). Any suggestions for alternatives?

That was disturbing news to me as well ;-( I’ll keep on doing _t in
existing code
to keep things consistent.

But for new code i’ve though of prefixing _td (TypeDef).

-david

[Kris_Eric_Warkentin]

Mario Charest <mcharest@voidzinformatic.com> wrote:

“David Alessio” <> david.alessio@hsa.hitachi.com> > wrote in message
news:> 3BCC825A.1162EBB4@hsa.hitachi.com> …

Some people like the meta-information of hungarian type variable names
and I believe Kernighan suggests it. I sometimes use a _p to
designate a pointer and almost always use a _t for typedefs.

That’s not portable. Names with trailing “_t” are “reserved for
implementation” by POSIX. I know that inside this building, we
control what our implementation defines, but if you’re writing an
application that you want to easily port to other OSes (or if you aren’t
a QNX employee), it’s good to adopt some other convention for your
typedefs.


Hmmm, I got used to this typedef name_t convention (didn’t know POSIX
claimed *_t). Any suggestions for alternatives?

That was disturbing news to me as well ;-( I’ll keep on doing _t in
existing code
to keep things consistent.

But for new code i’ve though of prefixing _td (TypeDef).


-david

I just liked it because the syntax highlighting in my editor would catch
*_t as a type and highlight it in the same way as int or char.

–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
“Computer science is no more about computers than astronomy is about telescopes”
–E.W.Dijkstra