Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: AUTO types doubt

Reply
Thread Tools

Re: AUTO types doubt

 
 
Eric Sosman
Guest
Posts: n/a
 
      10-05-2013
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
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      10-06-2013
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
(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      10-06-2013
Eric Sosman <(E-Mail Removed)> 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
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      10-06-2013
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
(E-Mail Removed)d
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-06-2013
rashan <(E-Mail Removed)> 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) (E-Mail Removed) <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"
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-08-2013
On Sun, 2013-10-06, Keith Thompson wrote:
> rashan <(E-Mail Removed)> 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 .
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-08-2013
Jorgen Grahn <(E-Mail Removed)> writes:
> On Sun, 2013-10-06, Keith Thompson wrote:
>> rashan <(E-Mail Removed)> 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) (E-Mail Removed) <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"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Auto Shipping Auto Shipping Scheduling:car moving auto transport linkswanted ASP .Net 1 11-22-2013 07:02 AM
Re: AUTO types doubt Nobody C Programming 25 11-15-2013 11:17 AM
The meaning of "doubt", was Re: Python Basic Doubt Peter Otten Python 2 08-10-2013 08:57 PM
dotnet doubt can any body clarify my doubt challa462@gmail.com ASP .Net 0 08-22-2012 06:02 AM
doubt about doubt Bob Nelson C Programming 11 07-30-2006 08:17 PM



Advertisments