Re: possible useful macros...

Discussion in 'C Programming' started by nick_keighley_nospam@hotmail.com, May 24, 2012.

  1. Guest

    On Wednesday, May 23, 2012 9:18:30 PM UTC+1, David T. Ashley wrote:

    <snip>

    > Macros and constants are overused.


    hardly ever

    > I've seen some awful things in my career.


    #define TWO 50

    (to be fair the language actually used didn't have character constants)

    > There is nothing wrong with magic numbers, and you can embed them
    > directly.


    no.

    > I've seen nonsense like this:
    >
    > #define TWICE 2
    > for (i=0; i<TWICE; i++) //Read the pushbutton twice, to be sure.
    > ...


    that's becasue a semantically meaningless name was chosen.

    #define BUTTON_REPEAT_COUNT 2

    > The only valid reasons to define a simple preprocessor substitution
    > are:
    >
    > a)When you change one instance, you have to change them all for the
    > program to be correct.
    >
    > b)The constant has a high probability of changing, and you'd like to
    > bundle all such things together where they can be changed without
    > hunting through the program.


    how do you know, up front, which constants have a high probability of change? PI isn't going to change, but what about DATA_SEPERATOR, MAXIMUM_TRANSCEIVERS, RETRY_COUNT

    > c)Symbolic clarity, i.e. "PI", "MAX_NUMBER_OF_TARGETS", etc.


    this is *the* major reason. Semantic clarity.

    Suppose these macros have all been replaced with embedded constants.

    #define SEPERATOR 9
    #define TX_COUNT 9
    #define RESPONSE_TIMEOUT 9
    #define ALARM_PORT 9

    and one of them changes, how do you ensure you change the correct instances?

    <snip>

    > I frankly don't even really approve of TRUE and FALSE. Why do it? The
    > semantics of how integers are interpreted are well-defined, so nothing
    > is wrong with:
    >
    > bMyDogBitMe = 1;


    ug. Not just embedded constants but hungarian notation to boot!

    <snip>
     
    , May 24, 2012
    #1
    1. Advertising

  2. John Gordon Guest

    In <> writes:

    > > bMyDogBitMe = 1;


    > ug. Not just embedded constants but hungarian notation to boot!


    I read an article on Hungarian notation and it actually sounded quite
    useful in its original form:

    http://www.joelonsoftware.com/articles/Wrong.html

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
     
    John Gordon, May 24, 2012
    #2
    1. Advertising

  3. Guest

    On Thursday, May 24, 2012 3:06:57 PM UTC+1, David T. Ashley wrote:
    > On Thu, 24 May 2012 00:29:56 -0700 (PDT),
    > wrote:
    > >On Wednesday, May 23, 2012 9:18:30 PM UTC+1, David T. Ashley wrote:


    > >> Macros and constants are overused.

    > >
    > >hardly ever


    they're distinctly *under-used*

    <snip>

    > >> There is nothing wrong with magic numbers, and you can embed them
    > >> directly.

    > >
    > >no.


    as in, I strongly disagree


    > >> I've seen nonsense like this:
    > >>
    > >> #define TWICE 2
    > >> for (i=0; i<TWICE; i++) //Read the pushbutton twice, to be sure.
    > >> ...

    > >
    > >that's becasue a semantically meaningless name was chosen.
    > >
    > >#define BUTTON_REPEAT_COUNT 2

    >
    > OK, you've given it a better name, but why bother with the
    > preprocessor if the constant is only used in one place?


    semantic clarity.

    > It just
    > forces the guy reviewing the code to look up one more thing.
    >
    > "2" is fine, as long as there is a comment there.


    the define /is/ the comment.

    > >> The only valid reasons to define a simple preprocessor substitution
    > >> are:
    > >>
    > >> a)When you change one instance, you have to change them all for the
    > >> program to be correct.
    > >>
    > >> b)The constant has a high probability of changing, and you'd like to
    > >> bundle all such things together where they can be changed without
    > >> hunting through the program.

    > >
    > >how do you know, up front, which constants have a high probability of change? PI isn't going to change, but what about DATA_SEPERATOR, MAXIMUM_TRANSCEIVERS, RETRY_COUNT

    >
    > Nonsense. Everyone writing a program has an intuitive feeling about
    > what is likely to change and what can change.


    ....and they are wrong. I've written highly flexible code that then remainedunchanged (or disappeared entirely) and I've hard-coded things that turnedout to be tremendously volatile.

    > By your logic, no "naked" integer or character constants (literals)
    > would exist, because any of them might change.


    exactly! You'd hate a review from me! I'll allow 0 and 1 everything else should be in a meaningfully named macro. And why limit this to integers? Floating point constants should also be macroised. And then there's path names and registry variables. Heck, some of these shouldn't be int the code at all- put them in a configuration file (XML if you must)

    I sometime stick bools in defines

    #define ERASE_WIND TRUE
    InvalidateRect(wind, rect, ERASE_WIND);

    > I reject that way of thinking.


    We'll just have to agree to diagree. I think you are simply wrong and flying in the face of decades (centuries?) of good engineering practice.

    read this http://en.wikipedia.org/wiki/The_Elements_of_Programming_Style
    first published 1974 but still relevent

    reead this http://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
    its for undergraduates but still a good read. It explains what abstraction is all about

    > >> c)Symbolic clarity, i.e. "PI", "MAX_NUMBER_OF_TARGETS", etc.

    > >
    > >this is *the* major reason. Semantic clarity.
    > >
    > >Suppose these macros have all been replaced with embedded constants.
    > >
    > >#define SEPERATOR 9
    > >#define TX_COUNT 9
    > >#define RESPONSE_TIMEOUT 9
    > >#define ALARM_PORT 9
    > >
    > >and one of them changes, how do you ensure you change the correct instances?

    >
    > "Instances" rather than "instance" is the key observation.


    I disagree. This is the same sort of logic that leads people to rufuse to break out a subroutine because "it's only called once". Besides how do you know its only going to be called once?

    <snip>

    > >> I frankly don't even really approve of TRUE and FALSE. Why do it? The
    > >> semantics of how integers are interpreted are well-defined, so nothing
    > >> is wrong with:
    > >>
    > >> bMyDogBitMe = 1;

    > >
    > >ug. Not just embedded constants but hungarian notation to boot!


    the "!" is rougly equivalent to ":)"

    > You're clearly a borderline nut case.


    riight so anyone who has a technical disagreement with you is crazy... Mostof computer science and software engineering is on my side not yours. I'veseen several programming standards that support my view.

    I've wasted a fair amount of my programming time debugging code written with rules similar to yours.

    > You want to overuse the preprocessor but also claim that embedding
    > type information in the variable name is a bad practice.


    because the type info will be nearby where the variable was declared. Have looked at any microsoft code? What happens when the type changes does the name? Answer: no not always.

    > Therapy and drugs is what you need.


    cheap shot. I hope I never have to maintain something you wrote.
     
    , May 25, 2012
    #3
  4. Guest

    On Thursday, May 24, 2012 3:23:50 PM UTC+1, John Gordon wrote:
    > In <> writes:
    >
    > > > bMyDogBitMe = 1;

    >
    > > ug. Not just embedded constants but hungarian notation to boot!

    >
    > I read an article on Hungarian notation and it actually sounded quite
    > useful in its original form:
    >
    > http://www.joelonsoftware.com/articles/Wrong.html


    yes I've read Joel's article (nice to read it again!) but he failed to convince me. I think the problems he describes could be handled with stronger typing.

    Simonyi Hungarian isn't as evil as Microsoft Hungarian (which is what bMyDogBitMe is) but I still think its fundamnetally wrong-headed.

    bMyDogBitMe is a violation of what i call extended third normal form or "Only Code It One Place". The type information is in more than one place. Bad.

    See DRY principle
     
    , May 25, 2012
    #4
  5. Guest

    On Friday, May 25, 2012 8:56:04 AM UTC+1, wrote:

    > bMyDogBitMe is a violation of what i call extended third normal form or "Only Code It One Place". The type information is in more than one place. Bad.
    >
    > See DRY principle


    from somewhere or other:-

    "•Don't Repeat Yourself (DRY)
    If you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change willoccur. Don't repeat yourself is important if you want flexible and maintainable software."
     
    , May 25, 2012
    #5
  6. David T. Ashley <> writes:
    [...]
    > You're clearly a borderline nut case.
    >
    > You want to overuse the preprocessor but also claim that embedding
    > type information in the variable name is a bad practice.
    >
    > Therapy and drugs is what you need.


    Consider being less obnoxious.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 25, 2012
    #6
  7. In article <>,
    Keith Thompson <> wrote:
    >David T. Ashley <> writes:
    >[...]
    >> You're clearly a borderline nut case.
    >>
    >> You want to overuse the preprocessor but also claim that embedding
    >> type information in the variable name is a bad practice.
    >>
    >> Therapy and drugs is what you need.

    >
    >Consider being less obnoxious.


    Leader Keith has spoken. All bow down.

    --
    Religion is regarded by the common people as true,
    by the wise as foolish,
    and by the rulers as useful.

    (Seneca the Younger, 65 AD)
     
    Kenny McCormack, May 25, 2012
    #7
  8. Guest

    On Friday, May 25, 2012 3:52:54 PM UTC+1, David T. Ashley wrote:
    > On Fri, 25 May 2012 00:45:48 -0700 (PDT),


    [nick believes pretty well all numeric constants should be hidden behind named constants]

    <snip>

    > > I hope I never have to maintain something you wrote.

    >
    > You have no idea of the horrors I've seen.


    I've seen a few horrors myself

    > When I have to review code, unless there is a really good reason to
    > introduce preprocessor symbols, it just makes useless work. In same
    > cases I've had to examine the preprocessor output ... useless work.


    as long as we're talking about simple constants then I profoundly disagree with your views. You are so wrong.

    > (Abstraction) and (use of the preprocessor) are two very different
    > topics.


    no. Abstraction can be achieved by sensible use of macros. If I was programming in C++ I wouldn't use macros for simple constants. But this is C so we're stuck with macros.

    > Not every macro or preprocessor constant represents
    > abstraction--most do not.


    disagree

    > The "one of" argument is interesting. I seem to remember that in the
    > early days of subroutines, subroutines were viewed as a code bulk
    > reduction mechanism rather than an abstraction mechanism. That view
    > gradually changed.


    not universally it didn't! People rarely say it out loud (though it's nor unknown) but often it's pretty clear what's going on.

    > I'm comfortable using a subroutine for a "one-of" operation (and often
    > do) because of the abstraction argument.


    ok

    > But macros seldom offer the
    > same level of abstraction (because the interface guarantees are
    > weaker, and you can place less complexity inside a macro). Most
    > "one-of" macros are flat out wasted typing.


    I think you're having an abstraction failure here. The fact that macros areused to define constants in C programs is simply an implementation detail.The point is to hide magic numbers (or other types) behind semantically meaningful abstractions. That's a large chunk of what programming is about.

    > I've found in watching software developers technically mature--or more
    > often, fail to mature--that they go through a phase very much like the
    > level of technical maturity expressed in your posts.


    hard to argue that one! I feel I have achieved a pretty good level of technical maturity- but then I would wouldn't I.

    To me your reluctance to use all the abstraction available to you is a signof technical immaturity.

    > I'd be curious if you have the same point of view in 10 years.


    I think you under-estimate both my age and my experience...

    > I'm not arguing against all use of preprocessor constants or
    > macros--I'm just saying that there has to be a good reason for it in
    > every case.


    yes. And avoiding scattering arbitary numeric values about the code seems like a pretty good reason to me!

    > More is less, and less is more. Terseness, compactness, and
    > directness are virtues.


    up to a point Lord Copper!

    Appropriate levels of abstraction are also virtues.

    Note that some of the Agile people regard comments as "code smells" (not a term I'm fond of- it means that the code in question is possibly flawed andshould be looked over with particular care); why use a magic number and comment it when you could use a sensibly named constant instead?

    Taken to extremes your view would limit us to single letter variables.
     
    , May 26, 2012
    #8
  9. Guest

    On Friday, May 25, 2012 7:41:53 PM UTC+1, Keith Thompson wrote:
    > David T. Ashley <> writes:


    > > You're clearly a borderline nut case.
    > >
    > > You want to overuse the preprocessor but also claim that embedding
    > > type information in the variable name is a bad practice.
    > >
    > > Therapy and drugs is what you need.

    >
    > Consider being less obnoxious.


    I know a couple of people who are diagnosed schizophrenics so I tend not to like the casual labelling of people merely because you disagree with them. For all he knows I might be a spas thlid.
     
    , May 26, 2012
    #9
  10. Guest

    On Friday, May 25, 2012 8:33:10 PM UTC+1, David T. Ashley wrote:
    > On Fri, 25 May 2012 00:56:04 -0700 (PDT),
    > wrote:
    > >On Thursday, May 24, 2012 3:23:50 PM UTC+1, John Gordon wrote:
    > >> In <> writes:


    > >> > > bMyDogBitMe = 1;
    > >>
    > >> > ug. Not just embedded constants but hungarian notation to boot!


    <snip>

    > >bMyDogBitMe is a violation of what i call extended third normal form or "Only Code It One Place". The type information is in more than one place. Bad.
    > >
    > >See DRY principle

    >
    > Actually, you've identified the right problem but the wrong cause.
    >
    > Information redundancy causes problems of all types in software
    > development and engineering in general. There are only two solutions:
    >
    > a)Find a way to keep the information in only one place, AND/OR
    >
    > b)Devise tools that either generate all of the redundant information
    > from a basis set or identify inconsistencies.


    ok

    > Here, I'm using "basis set" in the linear algebra sense, i.e.
    > http://tinyurl.com/ckcqcc8


    I remember basis sets and linear algebra

    > If you'd like type information available when you examine individual C
    > statements (which we all do) but at the same time you claim that it is
    > redundant to include this information in the variable name, then there
    > are two obvious solutions:


    yes I have kind of shot myself in the foot here. The Lispers would say attach type information to the values not the variables.

    (define var "hello) ; var contains a string
    (define var 23) ; var now contains a number


    > #1: Per (a) above, change the C language so that a variable's type is
    > automatically determined from the variable name, i.e. "vardec
    > bTheDogBitMe;" is equivalent to "BOOLEAN_T bTheDogBitMe;"--that way
    > the type isn't declared outside of the variable name.


    ah FOTRAN IV. If it began with I..N it was an INTEGER otherwise it was a FLOAT

    > #2: Per (b) above, devise tools that detect inconsistencies that
    > arise when a variable's type don't match the variable name.


    #3 don't wrte code that widely separates the type from the variable.

    > The problem that causes the information redundancy is actually the
    > definition of the C language, not Hungarian notation.


    I'm not convinced that well written code has a problem with this and I'm certain hungarian isn't the answer!
     
    , May 26, 2012
    #10
  11. Thad Smith Guest

    On 5/25/2012 4:12 AM, wrote:
    > On Friday, May 25, 2012 8:56:04 AM UTC+1, wrote:
    >
    >> bMyDogBitMe is a violation of what i call extended third normal form or "Only Code It One Place". The type information is in more than one place. Bad.
    >>
    >> See DRY principle

    >
    > from somewhere or other:-

    [Pragmatic Programmer by Hunt and Thomas]
    >
    > "•Don't Repeat Yourself (DRY)
    > If you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. Don't repeat yourself is important if you want flexible and maintainable software."


    I read the concept originally in the 1970s as Single Source Definition. I think
    it was from Glenford J Meyers, a pioneer in software engineering, but I haven't
    verified.

    I agree with Nick that using meaningful labels for constants is a useful
    abstraction. Macros are a tool. Use them wisely and they will help you.

    --
    Thad
     
    Thad Smith, Jun 12, 2012
    #11
  12. Guest

    On Tuesday, June 12, 2012 3:30:29 AM UTC+1, Thad Smith wrote:
    > On 5/25/2012 4:12 AM, wrote:
    > > On Friday, May 25, 2012 8:56:04 AM UTC+1, wrote:
    > >
    > >> bMyDogBitMe is a violation of what i call extended third normal form
    > >> or "Only Code It One Place". The type information is in more than one
    > >> place. Bad.
    > >>
    > >> See DRY principle

    > >
    > > from somewhere or other:-

    > [Pragmatic Programmer by Hunt and Thomas]
    > >
    > > "•Don't Repeat Yourself (DRY)
    > > If you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. Don't repeat yourself is important if you want flexible and maintainable software."

    >
    > I read the concept originally in the 1970s as Single Source Definition. I think
    > it was from Glenford J Meyers, a pioneer in software engineering, but I haven't verified.
    >
    > I agree with Nick that using meaningful labels for constants is a useful
    > abstraction. Macros are a tool. Use them wisely and they will help you.


    macros can be quite a dangerous tool. Using them to define simple constants
    is quite reasonable.
     
    , Jun 12, 2012
    #12
    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. Ben Pfaff

    Re: possible useful macros...

    Ben Pfaff, May 23, 2012, in forum: C Programming
    Replies:
    0
    Views:
    303
    Ben Pfaff
    May 23, 2012
  2. John Gordon

    Re: possible useful macros...

    John Gordon, May 23, 2012, in forum: C Programming
    Replies:
    3
    Views:
    302
    Phil Carmody
    Jun 11, 2012
  3. Kaz Kylheku

    Re: possible useful macros...

    Kaz Kylheku, May 23, 2012, in forum: C Programming
    Replies:
    0
    Views:
    242
    Kaz Kylheku
    May 23, 2012
  4. Lanarcam

    Re: possible useful macros...

    Lanarcam, May 23, 2012, in forum: C Programming
    Replies:
    1
    Views:
    232
    Bartc
    May 23, 2012
  5. Ike Naar

    Re: possible useful macros...

    Ike Naar, May 23, 2012, in forum: C Programming
    Replies:
    0
    Views:
    227
    Ike Naar
    May 23, 2012
Loading...

Share This Page