[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] WinAvr 2005... compile problems

From: Dave Hansen
Subject: Re: [avr-gcc-list] WinAvr 2005... compile problems
Date: Sun, 13 Mar 2005 11:00:41 -0500

From: "Graham Davies" <address@hidden>

Dave Hansen wrote:

> anyone who would create two symbols within a C program
> that could be used within the same context that differ only
> by the case of some characters would rightly be ridiculed

Well, I'd better step forward to be ridiculed, then.  I do this all the
time.  My personal coding style requires non-local variables to begin with
an uppercase letter and local variables with a lowercase letter.  If I want
to grab a non-local and do a lot with it then the local that holds it
temporarily has exactly the property you so deride.  Please ridicule
constructively if possible.

What a goofball.  ;-)  OK, not too constructive.

But it does sound like a bad idea. I generally don't make local copies of global variables unless it's a volatile value whose value I want to "freeze" for some section of code. But when I do it, I will definitely use a completely different symbol rather than one that varies only in the case of a letter or few. You remove the ability of the compiler to diagnose simple tpyos or Typographical errors for you.

In my own code, global variables get an all-caps prefix that identifies the module from which they come, e.g. TMR_ms might be (is, in several projects) a global free-running millisecond counter. If I wanted to record the value of this counter upon entry into a function, I might use something like

  uint8_t timestamp = TMR_ms;

In my code, capitalized symbols tend to indicate macros or typedefs, or at least things that aren't what they appear to be, e.g.,

  #define Is_Panel_Moving   BITS_1.bit.b0

where BITS_1 is a global union (defined in the module bits.c) with a uint8_t byte field, and a structure of 8 single-bit bit fields named bit.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]