Like Tree1Likes

May 2013 coding style discussion thread

This is a discussion on May 2013 coding style discussion thread within the Tech Board forums, part of the Community Boards category; <<< Split from http://cboard.cprogramming.com/c-pro...rs-struct.html >>> Originally Posted by rcgldr I seriously doubt that whether or not typedefs are in upper ...

  1. #1
    Registered User
    Join Date
    Jun 2005
    Posts
    6,625

    May 2013 coding style discussion thread

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

    Quote Originally Posted by rcgldr View Post
    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.
    Last edited by Salem; 05-12-2013 at 01:57 PM. Reason: split info
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  2. #2
    Registered User
    Join Date
    Apr 2013
    Posts
    1,338
    Quote Originally Posted by grumpy View Post
    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.

  3. #3
    Registered User
    Join Date
    Jun 2005
    Posts
    6,625
    Quote Originally Posted by rcgldr View Post
    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.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  4. #4
    Registered User
    Join Date
    Apr 2013
    Posts
    1,338
    Quote Originally Posted by grumpy View Post
    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?

  5. #5
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,406
    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
    Last edited by Salem; 05-12-2013 at 01:59 PM. Reason: fixed the fix

  6. #6
    Registered User
    Join Date
    Jun 2005
    Posts
    6,625
    Quote Originally Posted by rcgldr View Post
    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.

    Quote Originally Posted by rcgldr View Post
    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.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  7. #7
    Registered User
    Join Date
    Apr 2013
    Posts
    1,338
    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?

    Quote Originally Posted by grumpy View Post
    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?
    Last edited by rcgldr; 05-12-2013 at 08:55 AM.

  8. #8
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,406
    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

  9. #9
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,007
    Quote Originally Posted by rcgldr View Post
    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.
    rags_to_riches likes this.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,761
    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.

  11. #11
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,406
    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
    Last edited by phantomotap; 05-12-2013 at 08:40 PM.

  12. #12
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,761
    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.

  13. #13
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,265
    Quote Originally Posted by rcgldr
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  14. #14
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,406
    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

  15. #15
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,265
    Quote Originally Posted by phantomotap
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Is it bad style of coding ??
    By noobcpp in forum C++ Programming
    Replies: 15
    Last Post: 11-06-2008, 10:39 AM
  2. C++ Coding Standard Question/Discussion
    By Mastadex in forum C++ Programming
    Replies: 11
    Last Post: 08-13-2008, 11:54 AM
  3. Your Coding Style?
    By Krak in forum A Brief History of Cprogramming.com
    Replies: 45
    Last Post: 06-02-2005, 09:19 AM
  4. Coding style
    By Clyde in forum A Brief History of Cprogramming.com
    Replies: 21
    Last Post: 04-09-2002, 05:22 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21