Re: AUTO types doubt

Discussion in 'C Programming' started by Eric Sosman, Oct 5, 2013.

  1. Eric Sosman

    Eric Sosman Guest

    On 10/5/2013 4:52 AM, rashan wrote:
    > Dear friends
    >
    > I work for coding rules who say:
    >
    > " A local variable name should usually be different from the names of all
    > global variables. Where there is a good reason for reusing the name of a
    > global variable as a local variable, this variable must be declared with
    > an explicit auto to serve as a flag to others reading the code that the
    > name shadows a global identifier. "
    >
    > I thought auto was a C++ construction? However my C compiler will except
    > it. BUT auto is NOT necessary to shadow a global variable. At least in my
    > compiler.


    Others have explained the effect of `auto', but I think
    your question is about the "rule." Using `auto' on a variable
    whose name duplicates a global is not required by the C language,
    as you observe. It's a decree from someone in the organization,
    saying "In addition to what C itself requires, code written here
    shall also follow Rules One, Two, Three, ..."

    That someone apparently thinks using `auto' is a good way
    to flag a shadowing variable, to inform a later reader that the
    shadowing is intentional and not a mistake. (Personally, I think
    a comment would be more direct -- but I'm not the "someone" who
    makes the rules you work under.)

    If you read through the rest of the rules, you'll probably
    find other things C itself doesn't require -- indentation, for
    example, or the placement of {}, or the form and content of a
    copyright comment at the start of each file. This use of `auto'
    is similar: Local custom, not a consequence of choosing C.

    --
    Eric Sosman
    d
     
    Eric Sosman, Oct 5, 2013
    #1
    1. Advertising

  2. Eric Sosman

    Eric Sosman Guest

    On 10/5/2013 5:25 PM, rashan wrote:
    > On Sat, 05 Oct 2013 08:33:52 -0400, Eric Sosman wrote:
    >
    >> On 10/5/2013 4:52 AM, rashan wrote:
    >>> Dear friends
    >>>
    >>> I work for coding rules who say:
    >>>
    >>> " A local variable name should usually be different from the names of
    >>> all global variables. Where there is a good reason for reusing the name
    >>> of a global variable as a local variable, this variable must be
    >>> declared with an explicit auto to serve as a flag to others reading the
    >>> code that the name shadows a global identifier. "
    >>>
    >>> I thought auto was a C++ construction? However my C compiler will
    >>> except it. BUT auto is NOT necessary to shadow a global variable. At
    >>> least in my compiler.

    >>
    >> Others have explained the effect of `auto', but I think
    >> your question is about the "rule." Using `auto' on a variable whose
    >> name duplicates a global is not required by the C language,
    >> as you observe. It's a decree from someone in the organization, saying
    >> "In addition to what C itself requires, code written here shall also
    >> follow Rules One, Two, Three, ..."
    >>
    >> That someone apparently thinks using `auto' is a good way
    >> to flag a shadowing variable, to inform a later reader that the
    >> shadowing is intentional and not a mistake. (Personally, I think a
    >> comment would be more direct -- but I'm not the "someone" who makes the
    >> rules you work under.)
    >>
    >> If you read through the rest of the rules, you'll probably
    >> find other things C itself doesn't require -- indentation, for example,
    >> or the placement of {}, or the form and content of a copyright comment
    >> at the start of each file. This use of `auto' is similar: Local custom,
    >> not a consequence of choosing C.

    >
    > Yes also, required 8 spaces identation and { on next line no further
    > identation. However I believe this, is an irrelevant for auto use.
    >
    > So will you say the auto rule, is a mistake. Because it is NOT necessary
    > and also contradicts to C++.


    Not at all.

    First, it is not a "mistake" merely because C doesn't insist
    on it. C does not insist on meaningful identifiers, or on how
    much redundant white space you use and where, or on alphabetizing
    function definitions in a source file. C does not insist that you
    avoid `goto', or forbid you from using `#define QqV ;printf('. C
    does not even insist that you avoid undefined behavior! The
    things that C does and does not require are not, of themselves,
    a coding style.

    Second, its inapplicability to languages other than C does
    not qualify it as a "mistake." Perhaps it would be erroneous to
    use `auto' in C++, or in Fortran, or in Java, or in COBOL, or --
    who cares? The rules you're so wrought up over are for code
    written in C, not for code written in Python or Algol or SNOBOL.
    The fact that `auto' would not work (or would work differently) in
    PL/I does not mean that its use in C is in any way a "mistake."

    Summary: Life's too short. Move on.

    --
    Eric Sosman
    d
     
    Eric Sosman, Oct 6, 2013
    #2
    1. Advertising

  3. Eric Sosman <> wrote:

    (snip)

    > Second, its inapplicability to languages other than C does
    > not qualify it as a "mistake." Perhaps it would be erroneous to
    > use `auto' in C++, or in Fortran, or in Java, or in COBOL, or --
    > who cares? The rules you're so wrought up over are for code
    > written in C, not for code written in Python or Algol or SNOBOL.
    > The fact that `auto' would not work (or would work differently) in
    > PL/I does not mean that its use in C is in any way a "mistake."


    As far as I know, it works the same way in PL/I.

    I believe it is a legal abbreviation for AUTOMATIC which,
    as with C, is the default.

    But yes, coding conventions are conventions within what is legal
    to make programs more readable to others working together.
    Seems a little unusual, but a fine convention to me.

    -- glen
     
    glen herrmannsfeldt, Oct 6, 2013
    #3
  4. Eric Sosman

    Eric Sosman Guest

    On 10/5/2013 9:01 PM, Richard Damon wrote:
    > On 10/5/13 8:19 PM, Eric Sosman wrote:
    >>
    >> Second, its inapplicability to languages other than C does
    >> not qualify it as a "mistake." Perhaps it would be erroneous to
    >> use `auto' in C++, or in Fortran, or in Java, or in COBOL, or --
    >> who cares? The rules you're so wrought up over are for code
    >> written in C, not for code written in Python or Algol or SNOBOL.
    >> The fact that `auto' would not work (or would work differently) in
    >> PL/I does not mean that its use in C is in any way a "mistake."
    >>
    >> Summary: Life's too short. Move on.

    >
    > While C and C++ are different languages, they are also so similar in
    > many ways that, unless the shop bans C++, it would not make sense to
    > have a style guideline for C that forces code to be invalid C++ code,
    > unless it is for something that should be in C++. The scoping issue
    > being described is just a easy to happen in C++ (in fact there can be
    > more ways to cause this confusion).


    First, we're talking about a rule that applies to a collision
    between two dubious practices: Shadowing global variables, and using
    global variables in the first place. It's not only a corner case,
    it's a case in the corner of a dungeon.

    Second, we can debate from now until the cows come home whether
    this use of `auto' is a good one, and it will make no difference at
    all. I happen to think it's a poor choice (reason: It's a one-bit
    signal, and the association between that one bit and a particular
    "special" attribute has to be memorized externally; a comment would
    be better), but neither you nor I nor rashan is the person who needs
    convincing. If you don't like the rule argue with the rulemaker,
    not with someone else.

    Third, if C++ offers more opportunity for confusion a shop
    might be well-advised to ban it.

    And fourth, life's too short. Move on. (Or, "Get one, and
    move on.")

    > In fact, I use a general guideline that C code should not be written to
    > be make it more difficult than needed to convert it to C++, in
    > particular, I consider reserved symbols (like class) to be "reserved" in
    > C code. Note that this is a Guideline, and not a hard rule, if I need to
    > use something in C that isn't in C++, I will use it.


    Oddly enough, I take the opposite approach: I make a point
    of using `new' as an identifier in C code that allocates things,
    because it would very likely be a poor idea to transliterate
    such code to C++ without deeper examination.

    > The auto keyword in
    > this context doesn't fit that. This sounds like a documentation issue,
    > so the rule should be in the documentation, something like if you
    > intentionally create a variable hiding a global, add a comment to that
    > fact at the declaration.


    Yeah. More commonly, it'd be the other way around: Someone
    uses `zaphod' as an identifier in a function, and later on someone
    else comes along and invents a new global variable `zaphod'. There
    is no reason for the original coder to write

    int zaphod; // somebody might use this as a global someday

    .... and there's an excellent chance that the introducer of the global
    `zaphod' will be unaware of the local use among fifteen thousand
    source files. (Even if he greps for it first, there's a race between
    the grep and the code submission.) Using `auto' as a tag suffers
    from the same skew issue.

    LTS. Moving on.

    --
    Eric Sosman
    d
     
    Eric Sosman, Oct 6, 2013
    #4
  5. rashan <> writes:
    [...]
    > So will you say the auto rule, is a mistake. Because it is NOT necessary
    > and also contradicts to C++.


    Not at all. *No* style rules are "necessary", but having at least
    some style rules tends to be a good idea. It's not necessary to be
    consistent with your brace layout, but coding standards requiring
    consistency are a good idea. (I'm not, for the moment, advocating
    any specific layout style, just consistency.)

    And contradicting C++ is not necessarily a bad thing -- unless you
    might want to compile the same source code both as C and as C++,
    and the need for that is rare. (It does mean you can't use the
    same rule for C++ code, which isn't a problem if you don't use C++.)

    I don't particularly like the rule myself, because seeing "auto"
    on a declaration means nothing unless you're specifically aware of
    the rule.

    But if you don't like using "auto" on local variables that
    shadow global variables, the solution is simple: don't declare
    local variables that shadow global variables in the first place.
    (And you should usually try to avoid global variables altogether.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Oct 6, 2013
    #5
  6. Eric Sosman

    Jorgen Grahn Guest

    On Sun, 2013-10-06, Keith Thompson wrote:
    > rashan <> writes:
    > [...]
    >> So will you say the auto rule, is a mistake. Because it is NOT necessary
    >> and also contradicts to C++.

    ....

    > I don't particularly like the rule myself, because seeing "auto"
    > on a declaration means nothing unless you're specifically aware of
    > the rule.


    Yes. When you ask the question "how is this better than a comment
    saying 'here I'm shadowing a global'", the rule suddenly seems very
    strange.

    > But if you don't like using "auto" on local variables that
    > shadow global variables, the solution is simple: don't declare
    > local variables that shadow global variables in the first place.
    > (And you should usually try to avoid global variables altogether.)


    Yes again. The rule is strange, but completely harmless.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Oct 8, 2013
    #6
  7. Jorgen Grahn <> writes:
    > On Sun, 2013-10-06, Keith Thompson wrote:
    >> rashan <> writes:
    >> [...]
    >>> So will you say the auto rule, is a mistake. Because it is NOT necessary
    >>> and also contradicts to C++.

    > ...
    >
    >> I don't particularly like the rule myself, because seeing "auto"
    >> on a declaration means nothing unless you're specifically aware of
    >> the rule.

    >
    > Yes. When you ask the question "how is this better than a comment
    > saying 'here I'm shadowing a global'", the rule suddenly seems very
    > strange.


    Perhaps the point is to make it possible to check adherence to the rule
    automatically. A C parser could detect a local declaration that shadows
    another declaration, and complain if it doesn't have an explicit "auto"
    storage-class specifier. Parsing comments is also possible, but unlike
    with "auto" the compiler won't flag incorrect uses.

    [...]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Oct 8, 2013
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bob Nelson

    doubt about doubt

    Bob Nelson, Jul 28, 2006, in forum: C Programming
    Replies:
    11
    Views:
    629
  2. linkswanted
    Replies:
    1
    Views:
    925
  3. Replies:
    0
    Views:
    566
  4. Nobody

    Re: AUTO types doubt

    Nobody, Oct 5, 2013, in forum: C Programming
    Replies:
    25
    Views:
    313
    Tim Rentsch
    Nov 15, 2013
  5. Seebs

    Re: AUTO types doubt

    Seebs, Oct 6, 2013, in forum: C Programming
    Replies:
    106
    Views:
    977
    Geoff
    Oct 22, 2013
Loading...

Share This Page