May 2013 coding style discussion thread

[grumpy]

<<< Split from Array of pointers to a struct >>>

I seriously doubt that whether or not typedefs are in upper or lower case is going to cause confusion. There are already inconsistencies depending on the environment, for example, BYTE and DWORD in upper case while size_t is in lower case. Most Windows functions are mixed case, like CreateFile(), ... while std stuff is lower case, printf(), vector, ... .

You haven't been around the block enough. Essentially your argument amounts to "there is already inconsistency, so a bit more won't hurt".

Those "inconsistencies" you describe do contribute to confusion. Feeding those inconsistencies within your own coding style certainly does not reduce confusion. Humans cope with inconsistency, find ways to manage or work-around inconsistencies, and find ways to impose consistency. They do this because inconsistency is not an attribute that contributes to any improvement in human comprehension and human productivity. Quite the reverse.

You might get away with a haphazard approach in small developments - like homework exercises. The problem is that what you can get away with in small developments causes considerable problems in larger developments. In larger developments, the impacts of inconsistency are commensurately larger (in formal language, the impacts grow faster than linearly with various measures of program size), and you will not get away with them.

[rcgldr]

In larger developments, the impacts of inconsistency are commensurately larger (in formal language, the impacts grow faster than linearly with various measures of program size), and you will not get away with them.

In a larger development, you're generally going to have some type of corporate coding standard to comply with, so any naming inconsistencies will be due the libraries used by the team, not due to poor choices made by individual members. There are a lot of other coding standard issue that have much more impact than which case is used for typedefs. One of my pet pet peeves is "arrow code"

Coding Horror: Flattening Arrow Code

Fortunately, I've rarely seen this used in a corporate environment.

[grumpy]

In a larger development, you're generally going to have some type of corporate coding standard to comply with, so any naming inconsistencies will be due the libraries used by the team, not due to poor choices made by individual members.

Poor choices made by individual team members are among the most common cause of problems, even when there is a corporate coding standard, a team that actively seeks to comply with that standard, and there is active monitoring (eg code reviews) and enforcement (rewards for evidence of good practice, consequences like lost bonuses for evidence of poor practice).

Endorsing poor practices in "personal" or "small" code - which is what you are doing - encourages programmers to develop an attitude of "it doesn't matter". Apart from increasing chances of them muffing their own projects (or homework) that encourages an attitude that can make them unsuitable for any professional development. Even a hint of an "it doesn't matter" attitude routinely knocks candidates out of contention in a job interview.


The "flattening arrow" syndrome is low-hanging fruit. It has a very visible impact, which is easy to find, and therefore easy to eliminate. It is therefore picked up quite easily in routine code reviews, and easily eliminated. That is not so true with little things, like naming and capitalisation conventions, since those have subtle impacts that are very hard to detect (even with compilers that insist on all identifiers being declared, and are case-sensitive) and therefore result in obscure bugs that can be quite difficult to eliminate.

[rcgldr]

Endorsing poor practices in "personal" or "small" code - which is what you are doing.

I never endorsed "poor practices". I only stated that it's common to create typedefs for pointers (for example microsoft), and the choice of using upper case or lower case for typedefs doesn't really matter, and that in the "real world", there's a lot of variation. Most of windows uses "Hungarian" style naming convention (mixed case), while the standard template library is almost all lower case (if not all lower case).

How is any of this helping the original poster with his code?

[phantomotap]

O_o

1): typedefs for pointers
2): using [uppercase] for typedefs
3): uses "Hungarian" style naming convention

These are indeed examples of "poor practices".

1): Using a pointer directly alleviates some of the potential confusion of value or reference semantics; code that "self-documents" is better code.
2): Using all uppercase for a `typedef' violates the canonical assumption of an all uppercase label being a processor token; a processor token and a `typedef' may have hugely different semantics so by limiting all uppercase labels to processor tokens you, again, reduce the potential for confusion.
3): "Hungarian" is the worst naming convention in the history of programming. (Microsoft, where it was born, specifically recommends that no new code be written against "Hungarian" notation.) The use of "Hungarian" in a language like C or C++ is redundant at even the best of times, but the common case is actually detrimental to reasoning about code.

Bonus): "Hungarian" notation has nothing to do with "CamelCase" except in that "Hungarian" employees "CamelCase". What you are calling "mixed case", `WhichLooksLikeThis', is "CamelCase". (Yes, "CamelCase" has other names, but "Hungarian" is not one of them.) "Hungarian" notation is a naming scheme that, basically, documents that type of a variable as a prefix within a variables label.

[Edit]
Sorry for the duplicate post; I got a database error after posting; I tried, and failed, to delete it multiple times.
<< fixed >>
[/Edit]

Soma

[grumpy]

I never endorsed "poor practices".

You did say it doesn't matter if certain practices are used. That is sanctioning their use. One of the dictionary definitions of endorsement is "sanctioning or approving".

The particular practices you have thus endorsed are ones that experienced practitioners (and also a number of recognised experts on both C and C++, in published books and articles) consider to be poor practice.

How is any of this helping the original poster with his code?

Salem pointed out examples of recognised bad practice in the OPs code. You endorsed that bad practice. My response is to dispute your endorsement and to provide reasoning. Who is being unhelpful? The OP can decide for him/herself.

[rcgldr]

Again this continues to go off topic. If there's a moderator here, can the coding style debate part of this thread be split off into another thread?

Salem pointed out examples of recognised bad practice in the OPs code. You endorsed that bad practice.

I stated that it didn't matter because you'll find instances typedefs for pointers and typedefs in all upper case for windows based programming (there may be other instances of such usage, but windows is a common example). Microsoft continues to use hungarian naming convention with any new functions added for windows programming in order to be consistent with its existing coding style. Linux / Posix / Unix have their own coding styles. That doesn't make one style bad and the other good, they're just different.

Can you show me an article from a well known and/or trusted author that states that using typedefs for pointers or all upper case typedefs is recognized bad programming practice?

Note that the wiki article for typedefs includes typedefs for pointers:

typedef - Wikipedia, the free encyclopedia

As for all upper case typedefs, here's an article for a university class that includes this requirement: Macros, typedefs and enums must be all upper case

C Style Summary

If you really want to debate this, why not start up a thread at msdn forums rather than this poor guy's thread?

[phantomotap]

If you really want to debate this, why not start up a thread at msdn forums rather than this poor guy's thread?

If you didn't want to debate this, why did you defend such bad practices when Salem pointed them out?

I'm being serious here, if you didn't think it was worth discussing, to point out that what Salem had pointed out was, in your opinion, "not a problem", why did you respond in the first place?

Soma

[Elysia]

As for all upper case typedefs, here's an article for a university class that includes this requirement: Macros, typedefs and enums must be all upper case

Don't find some random school education page for your reference as to something being good or bad practice.
There is a ton of bad practice out there and many schools--tons of schools--follow these bad practices, especially those in India.
The fact that the page says that there are certain style rules that must be followed disqualifies this site. Style is individual. There is no must.

[whiteflags]

Don't find some random school education page for your reference as to something being good or bad practice.
There is a ton of bad practice out there and many schools--tons of schools--follow these bad practices, especially those in India.

Oddly enough, this is also poisoning the well: You refuse to evaluate information from a school site and encourage other people to dismiss it outright.

The fact that the page says that there are certain style rules that must be followed disqualifies this site. Style is individual. There is no must.

It isn't disqualified if you go to that university and are instructed to do homework in that style. If companies can establish style guidelines, so can schools.

That's all I really want to say, by the way. I think you're being just as biased as the other person if you think following someone else's guidelines is a mistake.

[phantomotap]

You refuse to evaluate information from a school site and encourage other people to dismiss it outright.

O_o

You make a good point.

@Elysia: Why should the newbie or rcgldr listen to us and not them? Throwing "They are bad." isn't really sufficient; consider giving examples as to why such guidelines are bad.

I think you're being just as biased as the other person if you think following someone else's guidelines is a mistake.

In fairness, many guides are themselves mistakes, and following a bad style is a mistake.

Yes, sometimes businesses or schools do set guidelines one must follow. I don't think anyone has suggested otherwise.

The issue here though is suggesting, defending even, that a newbie continue to follow bad style that violates canonical expectations because it is "not a problem".

Yes, in isolation a newbie using uppercase for every type is not really all that bad.

Yes, even here the newbie in question may be forced to follow such a guideline.

None of that matters though, we don't want people learning to follow bad guidelines that violate canonical standards for the same reason we do want people to learn best practices: the code people produce will be easier to reason about.

Soma

[whiteflags]

I guess I'm just jaded to the whole thing and it doesn't really matter to me, as long as whatever you do it's consistent. I know what the issue is, but that doesn't excuse what Elysia posted. Like I said, that's all I wanted to say.

[laserlight]

Can you show me an article from a well known and/or trusted author that states that using typedefs for pointers or all upper case typedefs is recognized bad programming practice?

Don't have the book with me right now, but if I remember correctly, Sutter & Alexandrescu's C++ Coding Standards recommends against using fully capitalised identifiers for things other than constants. Of course, if you are working a code base where the style is already to use fully capitalised identifiers for something else, then consistency trumps the advantage of not confusing constants with other things.

It should be easy enough to see why typedefs for pointers are bad practice: try them yourself and then experience what value (or lack thereof) the typedef brings when you have to remember that the type is a pointer type and hence pointer syntax should be used, otherwise the typedef name must include "pointer" or some variant thereof making it rather redundant. That said, there are valid uses of pointer typedefs, e.g., to typedef an opaque pointer type when exposing an interface (sensible, since pointer syntax must not be used), or in the case of C++, when a random access iterator is needed and hence a pointer fits the bill.

[phantomotap]

I guess I'm just jaded to the whole thing and it doesn't really matter to me, as long as whatever you do it's consistent.

O_o

I appreciate that, but I guess I too am "jaded" or something along those lines.

It upsets me to no end how many schools are dumping crap programmers into my field.

since pointer syntax must not be used

o_O

I don't follow. Example?

Soma

[laserlight]

I don't follow. Example?

For example, you cannot dereference an opaque pointer since the definition of the type of what the pointer points to is unknown at that point.