C++ Coding Standards : 101 Rules, Guidelines, and Best Practices

Discussion in 'C++' started by Stuart Gerchick, Oct 31, 2004.

  1. C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
    Herb Sutter, Andrei Alexandrescu is now a month or so away from
    release. What is people's opinion on this...is it going to be a
    seminal work or lackluster

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Stuart Gerchick, Oct 31, 2004
    #1
    1. Advertising

  2. Stuart Gerchick

    Mike Wahler Guest

    "Stuart Gerchick" <> wrote in message
    news:...
    > C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
    > Herb Sutter, Andrei Alexandrescu is now a month or so away from
    > release. What is people's opinion on this...is it going to be a
    > seminal work or lackluster


    If I were capable of predicting the future, I'd be heading
    for Las Vegas or Wall Street. And I can't give an opinion
    about the literature itself, since I haven't seen it. However
    I suspect it will be of value to many, based upon the reputations
    of Herb & Andrei.

    -Mike
     
    Mike Wahler, Oct 31, 2004
    #2
    1. Advertising

  3. Stuart Gerchick

    Herb Sutter Guest

    On 31 Oct 2004 06:17:29 -0500, (Stuart Gerchick)
    wrote:
    >C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
    >Herb Sutter, Andrei Alexandrescu is now a month or so away from
    >release.


    In North America, it should be available in bookstores around now. Andrei
    and I got our first copies a week ago, and it was available for sale at
    OOPSLA. I haven't looked at my local Barnes & Noble or Borders yet.

    More at http://pluralsight.com/blogs/hsutter/archive/2004/10/07/2709.aspx
    ...

    Herb

    ---
    Herb Sutter (www.gotw.ca) (www.pluralsight.com/blogs/hsutter)

    Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
    Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
    Architect, Developer Division, Microsoft (www.gotw.ca/microsoft)

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Herb Sutter, Nov 1, 2004
    #3
  4. Stuart Gerchick

    apm Guest

    (Stuart Gerchick) wrote in message
    news:<>...
    > C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
    > Herb Sutter, Andrei Alexandrescu is now a month or so away from
    > release. What is people's opinion on this...is it going to be a
    > seminal work or lackluster


    Judging from the table of contents, it looks good. It seems to sum up
    several pearls of wisdom from sources such as Meyers I, II, III and
    GoTW. It looks like it is going to avoid the more contravesial
    style-oriented guidelines, and so to me, does not appear to be like
    other coding guidelines. I think it is more tutorial in nature and
    thus may not be suitable for use by QA during code review. But who
    knows, until it is actually published?

    Regards,

    Andrew Marlow

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    apm, Nov 1, 2004
    #4
  5. Herb Sutter <> wrote in message news:<>...
    > On 31 Oct 2004 06:17:29 -0500, (Stuart Gerchick)
    > wrote:
    > >C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
    > >Herb Sutter, Andrei Alexandrescu is now a month or so away from
    > >release.

    >
    > In North America, it should be available in bookstores around now. Andrei
    > and I got our first copies a week ago, and it was available for sale at
    > OOPSLA. I haven't looked at my local Barnes & Noble or Borders yet.
    >
    > More at http://pluralsight.com/blogs/hsutter/archive/2004/10/07/2709.aspx
    > ..
    >
    > Herb


    I didn't expect Herb Sutter himself to respond to this posting. I am
    eagerly awaiting it actually and cant wait to have it in my hands.
    Unfortunately, I am in the UK most of the time these days, and will
    have to wait a bit for the release. I have it on order and it should
    arrive soon.

    Thank for for your time Herb. I appreciate it

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Stuart Gerchick, Nov 2, 2004
    #5
  6. Stuart Gerchick

    Stephen Howe Guest

    >What is people's opinion on this...is it going to be a seminal work or
    lackluster

    With the book not released, how are we supposed to judge? And what do
    people's opinions matter, at all, with so little to go on?

    Stephen Howe



    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Stephen Howe, Nov 2, 2004
    #6
  7. Stuart Gerchick

    Guest

    (Stuart Gerchick) wrote in message
    news:<>...

    > C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
    > Herb Sutter, Andrei Alexandrescu is now a month or so away from
    > release.


    At least some of the people I know have seen actual copies of the
    printed book. (On the other hand, Amazon says "not yet been released".)

    > What is people's opinion on this...is it going to be a seminal work or
    > lackluster


    How can anyone tell if they've not actually seen the book. And I'm not
    quite sure what you mean by "seminal" -- I wouldn't have considered it
    an antonym for lackluster. Given the authors, I expect lots of useful
    information, and a readable style. Given the authors, I also expect
    some information "just for fun", and some information which won't be
    immediately usable because compilers and/or collegues who have to read
    and understand the code aren't up to date. On the other hand, by
    "seminal", I understand something that will change the way we think
    about the language -- a priori, I don't expect either author to present
    new ideas that they haven't already discussed here, for example. (In
    the industry, from a pratical point of view, "seminal" often means,
    "interesting, but not usable in the next ten years". While some of
    Andrei's work might fall into that category -- especially if you have
    difficulty getting updates for your collegues:), for the most part, I
    expect that most of the information in the book will be immediately
    usable.)

    --
    James Kanze GABI Software http://www.gabi-soft.fr
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    , Nov 2, 2004
    #7
  8. "Stephen Howe" <> wrote in
    message news:<4187892b$0$446$>...
    > >What is people's opinion on this...is it going to be a seminal work or

    > lackluster
    >
    > With the book not released, how are we supposed to judge? And what do
    > people's opinions matter, at all, with so little to go on?
    >
    > Stephen Howe


    As Herb Sutter said above it was available for sale at OOPSLA. People
    have now seen it. The kinds of people who are on comp.lang.c++

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Stuart Gerchick, Nov 5, 2004
    #8
  9. Stuart Gerchick

    ma740988 Guest

    (Stuart Gerchick) wrote in message news:<>...
    > C++ Coding Standards : 101 Rules, Guidelines, and Best Practices by
    > Herb Sutter, Andrei Alexandrescu is now a month or so away from
    > release. What is people's opinion on this...is it going to be a
    > seminal work or lackluster



    I approach it from the standpoint that book (my copy showed up
    yesterday) - as the title says - is a collection of 'best practices'.

    Paragraph 3, page xiii states

    " The coding standards introduced by this book are collection of
    guidelines for writing high-quality C++ code. They are distilled
    conclusions of a rich collective experience of the C++ community.
    Much of this body of knowledge has only been available in bits and
    pieces spread throughout books, or as word-of-mouth wisdom. This
    book's intent is to collect that knowledge into a collection of rules
    that is terse, justified, and easy to understand and follow".

    The key IMO starts here "This book's intenet .. follow".

    Here's one that I'm still confused - if you will - on what constitutes
    the ideal implementation approach.

    42 per the text. Dont give away your internals

    Accessor and mutator as I understand it are - for the most part -
    design flaws.
    The example in the text shows a GetBuffer member function returing a
    char*
    In any event, when data needs to be shared among classes this
    accessor/mutator beats the alternative (public member data) so I've
    never quite understood this one.
    A host of get and sets - I suspect - are signs of poor design. I'd
    still like to see a concrete example that shows the solution.

    My 2cents for what it's worth.

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    ma740988, Nov 6, 2004
    #9
  10. Hi!

    Stuart Gerchick wrote:
    > People
    > have now seen it. The kinds of people who are on comp.lang.c++


    There are also European people on this newsgroup, like me. And
    they don't have the book yet.

    Frank


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Frank Birbacher, Nov 7, 2004
    #10
  11. Stuart Gerchick

    Phlip Guest

    getters and setters [Was: C++ Coding Standards]

    ma740988 wrote:

    > 42 per the text. Dont give away your internals
    >
    > Accessor and mutator as I understand it are - for the most part -
    > design flaws.
    > The example in the text shows a GetBuffer member function returing a
    > char*
    > In any event, when data needs to be shared among classes this
    > accessor/mutator beats the alternative (public member data) so I've
    > never quite understood this one.
    > A host of get and sets - I suspect - are signs of poor design. I'd
    > still like to see a concrete example that shows the solution.


    OO design is about behavior. Classes should tell others what to do. If a
    class takes data out of another, manipulates it, and puts it back in, then
    the behavior is in the wrong class.

    If you indeed share data, then this "data transfer object" should be a
    separate thing, without any behavior, and the classes should pass it around.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Phlip, Nov 7, 2004
    #11
  12. Re: getters and setters [Was: C++ Coding Standards]

    Phlip wrote:


    > OO design is about behavior. Classes should tell others what to do. If a
    > class takes data out of another, manipulates it, and puts it back in, then
    > the behavior is in the wrong class.


    I don't know how widely shared that opinion is. One view of OOP is
    expressed in Roman Mäder's _Computer Science With Mathematica_ as follows:
    "An object is, therefore, a collection of data elements together with the
    functions operating on them."

    > If you indeed share data, then this "data transfer object" should be a
    > separate thing, without any behavior, and the classes should pass it
    > around.
    >


    So, for example, and int should have a wrapper class called Integer?
    --
    "If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true." - Bertrand
    Russell


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Steven T. Hatton, Nov 7, 2004
    #12
  13. Stuart Gerchick

    Phlip Guest

    Re: getters and setters [Was: C++ Coding Standards]

    Steven T. Hatton wrote:

    > Phlip wrote:


    > > OO design is about behavior. Classes should tell others what to do. If a
    > > class takes data out of another, manipulates it, and puts it back in,

    then
    > > the behavior is in the wrong class.

    >
    > I don't know how widely shared that opinion is. One view of OOP is
    > expressed in Roman Mäder's _Computer Science With Mathematica_ as follows:
    > "An object is, therefore, a collection of data elements together with the
    > functions operating on them."


    Designing a program means organizing the relations between its structure in
    memory and their behavior in time.

    OO design is about partitioning that behavior with polymorphism.

    I am aware that the entry-level tutorials describe objects as data and the
    functions that operate on them. You can also find tutorials that say "OO
    objects are like real-world objects".

    > > If you indeed share data, then this "data transfer object" should be a
    > > separate thing, without any behavior, and the classes should pass it
    > > around.

    >
    > So, for example, and int should have a wrapper class called Integer?


    Why?

    It's the same question as before - what is an int's behavior? If it has only
    a little, then it's a "value object", and unbeholden to any one class.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Nov 7, 2004
    #13
  14. Re: getters and setters [Was: C++ Coding Standards]

    Phlip wrote:

    > Steven T. Hatton wrote:
    >
    >> Phlip wrote:

    >
    >> > OO design is about behavior. Classes should tell others what to do. If
    >> > a class takes data out of another, manipulates it, and puts it back in,

    > then
    >> > the behavior is in the wrong class.

    >>
    >> I don't know how widely shared that opinion is. One view of OOP is
    >> expressed in Roman Mäder's _Computer Science With Mathematica_ as
    >> follows: "An object is, therefore, a collection of data elements together
    >> with the functions operating on them."

    >
    > Designing a program means organizing the relations between its structure
    > in memory and their behavior in time.
    >
    > OO design is about partitioning that behavior with polymorphism.


    Not all classes exhibit polymorphism. How do the so-called concrete classes
    fit into your model?

    > I am aware that the entry-level tutorials describe objects as data and the
    > functions that operate on them. You can also find tutorials that say "OO
    > objects are like real-world objects".


    What I quoted from is a textbook used at ETH in Zrich. Perhaps you've heard
    of the University? It's where Einstein got his degree in Physics.

    >> > If you indeed share data, then this "data transfer object" should be a
    >> > separate thing, without any behavior, and the classes should pass it
    >> > around.

    >>
    >> So, for example, and int should have a wrapper class called Integer?

    >
    > Why?
    >
    > It's the same question as before - what is an int's behavior? If it has
    > only a little, then it's a "value object", and unbeholden to any one
    > class.


    I guess I'm confused about what you mean by shared data. Using set and get
    methods is not typically considered sharing data. If I have a class called
    Arrow which has different properties such as color, length, position,
    rotation, etc., how am I supposed to manipulate objects of that class in
    order to change these properties? Am I expected not to be interested in
    the current value of these objects at runtime? If I am interested in
    observing these values, then how am I expected to access them without 'get'
    methods?

    If I understand the opinion that I should not use set and get methods, it
    means I should not have code such as that shown below. Is that what you
    are trying to suggest?

    class Light{
    //...
    virtual const array<GLfloat,4>& ambient() const {return _ambient; }

    virtual void ambient(const array<GLfloat,4>& ambient_)
    {
    _ambient = ambient_;
    }


    virtual const array<GLfloat,4>& diffuse() const {return _diffuse; }

    virtual void diffuse(const array<GLfloat,4>& diffuse_)
    {
    _diffuse = diffuse_;
    }


    virtual const array<GLfloat,4>& specular() const {return _specular; }

    virtual void specular(const array<GLfloat,4>& specular_)
    {
    _specular = specular_;
    }


    virtual const array<GLfloat,4>& ambientModel() const
    {
    return _ambientModel;
    }

    virtual void ambientModel(const array<GLfloat,4>& ambientModel_)
    {
    _ambientModel = ambientModel_;
    }

    virtual GLenum light() const {return _light; }

    virtual void light(GLenum light_)
    {
    _light = light_;
    }


    protected:
    array<GLfloat,4> _position;
    array<GLfloat,4> _ambient;
    array<GLfloat,4> _diffuse;
    array<GLfloat,4> _specular;

    array<GLfloat,4> _ambientModel;

    GLenum _light;
    };

    --
    "If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true." - Bertrand
    Russell
     
    Steven T. Hatton, Nov 7, 2004
    #14
  15. Stuart Gerchick

    Phlip Guest

    Re: getters and setters [Was: C++ Coding Standards]

    Steven T. Hatton wrote:

    > > Designing a program means organizing the relations between its structure
    > > in memory and their behavior in time.
    > >
    > > OO design is about partitioning that behavior with polymorphism.

    >
    > Not all classes exhibit polymorphism. How do the so-called concrete

    classes
    > fit into your model?


    Another aspect of design is how easily it can change. Most methods should
    not be virtual, and most re-use should be delegated, not inherited.

    > > I am aware that the entry-level tutorials describe objects as data and

    the
    > > functions that operate on them. You can also find tutorials that say "OO
    > > objects are like real-world objects".

    >
    > What I quoted from is a textbook used at ETH in Zrich. Perhaps you've

    heard
    > of the University? It's where Einstein got his degree in Physics.


    I'm sitting on the same landmass as Cal Tech. Perhaps you have heard of Cal
    Tech? It's where they invented something that I decline to look up with
    Google.

    I could let your fallacy of "appeal to authority" slide, except you seem to
    think you are arguing with me about something. I'm not sure what.

    The point: Classes should minimize getters and setters, because they should
    expose access to behaviors.

    > I guess I'm confused about what you mean by shared data. Using set and

    get
    > methods is not typically considered sharing data. If I have a class

    called
    > Arrow which has different properties such as color, length, position,
    > rotation, etc., how am I supposed to manipulate objects of that class in
    > order to change these properties? Am I expected not to be interested in
    > the current value of these objects at runtime? If I am interested in
    > observing these values, then how am I expected to access them without

    'get'
    > methods?


    Okay, I'm going to make a great effort to agree with you here, but I need
    you to know that before I start, because I'm trying to avoid one of /those/
    threads...

    Consider this graphic:

    A -> B

    The "behavior" of -> is that it points at B. However, if we move B...

    A ->
    B

    ....then -> no longer points at B. Let's call that behavior "extrinsic".

    ->'s intrinsic behavior is its tail is there and its head is here, etc. Set
    these behaviors with setters.

    Limit your application's access to those setters. A class aware of A -> B
    could respond to high-level commands that move B by fixing the extrinsic
    behavior of the arrow. However, that AB class should not make its awareness
    of -> public. The buck stops here.

    Encapsulation is hierarchical. The rule "Don't make primitive things
    globally public" is more useful than the rule "don't make data members
    public".

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Nov 7, 2004
    #15
  16. Re: getters and setters [Was: C++ Coding Standards]

    Phlip wrote:

    > Steven T. Hatton wrote:
    >> Not all classes exhibit polymorphism. How do the so-called concrete

    > classes
    >> fit into your model?

    >
    > Another aspect of design is how easily it can change. Most methods should
    > not be virtual, and most re-use should be delegated, not inherited.


    That really depends on what you are designing. IMO, if you make one member
    function virtual, you should have a good reason /not/ to make the remainder
    virtual. I'll follow Stroustrup's convention of reserving the term
    "method" for pure virtual member functions.

    > I could let your fallacy of "appeal to authority" slide, except you seem
    > to think you are arguing with me about something. I'm not sure what.


    There is no fallacy in appeal to authority when the subject is one of widely
    help opinions in a field. The opinions of authorities in the field
    constitute the topic.

    > The point: Classes should minimize getters and setters, because they
    > should expose access to behaviors.


    The fundamental concept of object oriented programming is the idea of data
    objects combined with associated operators.

    > Okay, I'm going to make a great effort to agree with you here, but I need
    > you to know that before I start, because I'm trying to avoid one of
    > /those/ threads...
    >
    > Consider this graphic:
    >
    > A -> B
    >
    > The "behavior" of -> is that it points at B. However, if we move B...
    >
    > A ->
    > B
    >
    > ...then -> no longer points at B. Let's call that behavior "extrinsic".
    >
    > ->'s intrinsic behavior is its tail is there and its head is here, etc.
    > Set these behaviors with setters.
    >
    > Limit your application's access to those setters. A class aware of A -> B
    > could respond to high-level commands that move B by fixing the extrinsic
    > behavior of the arrow. However, that AB class should not make its
    > awareness of -> public. The buck stops here.
    >
    > Encapsulation is hierarchical. The rule "Don't make primitive things
    > globally public" is more useful than the rule "don't make data members
    > public".
    >


    This seems like a far weaker statement than the idea that using set and get
    methods indicated a probable design flaw. That was, IIRC, the point at
    which this thread forked. Stroustrup makes a similar assertion in
    TC++PL(SE) regarding set and get methods. I have questioned that in this
    newsgroup, and I have never been convinced of the merits of the general
    guideline. Perhaps a better statement might be 'Be judicious in what you
    expose through accessor methods'. That I can agree with.
    --
    "If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true." - Bertrand
    Russell
     
    Steven T. Hatton, Nov 7, 2004
    #16
  17. Stuart Gerchick

    osmium Guest

    Re: getters and setters [Was: C++ Coding Standards]

    Someone wrote:

    > > Accessor and mutator as I understand it are - for the most part -
    > > design flaws.
    > > The example in the text shows a GetBuffer member function returing a
    > > char*
    > > In any event, when data needs to be shared among classes this
    > > accessor/mutator beats the alternative (public member data) so I've
    > > never quite understood this one.
    > > A host of get and sets - I suspect - are signs of poor design. I'd
    > > still like to see a concrete example that shows the solution.


    You are asking for a concrete solution to an unexpressed problem. Remember
    we can't see what you are looking at in a book.



    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    osmium, Nov 7, 2004
    #17
  18. Stuart Gerchick

    Phlip Guest

    Re: getters and setters [Was: C++ Coding Standards]

    Steven T. Hatton wrote:

    > This seems like a far weaker statement than the idea that using set and

    get
    > methods indicated a probable design flaw.


    Using getters and setters indicates a probable design flaw.

    > That was, IIRC, the point at
    > which this thread forked. Stroustrup makes a similar assertion in
    > TC++PL(SE) regarding set and get methods. I have questioned that in this
    > newsgroup, and I have never been convinced of the merits of the general
    > guideline. Perhaps a better statement might be 'Be judicious in what you
    > expose through accessor methods'. That I can agree with.


    Encapsulation is hierarchical. The root principle of OO is encapsulation of
    indirection. Without polymorphism there is no OO. (Regardless of whether a
    given program happens to use virtuals.)

    "Data objects with the methods that operate on them" is just "object based".

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Nov 8, 2004
    #18
  19. Re: getters and setters [Was: C++ Coding Standards]

    Phlip wrote:

    > Steven T. Hatton wrote:
    >
    >> This seems like a far weaker statement than the idea that using set and

    > get
    >> methods indicated a probable design flaw.

    >
    > Using getters and setters indicates a probable design flaw.


    In your unsubstantiated opinion.

    >> That was, IIRC, the point at
    >> which this thread forked. Stroustrup makes a similar assertion in
    >> TC++PL(SE) regarding set and get methods. I have questioned that in this
    >> newsgroup, and I have never been convinced of the merits of the general
    >> guideline. Perhaps a better statement might be 'Be judicious in what you
    >> expose through accessor methods'. That I can agree with.

    >
    > Encapsulation is hierarchical. The root principle of OO is encapsulation
    > of indirection. Without polymorphism there is no OO. (Regardless of
    > whether a given program happens to use virtuals.)
    >
    > "Data objects with the methods that operate on them" is just "object
    > based".


    My reason for saying the fundamental concept of object oriented programming
    is the idea of data objects combined with associated operators, is based on
    a comment in Ole-Johan Dahl's The *Birth of Object Orientation: the Simula
    Languages*:

    "... The example shows that the idea of data objects with associated
    operators was under way already in 1965."

    That seems to be the watershed in his mind as to when OOP first appeared. I
    will note that he subsequently adds:

    "There is universal use of the term "object orientation", OO. Although no
    standard definition exists, some or all of the above ideas enter into the
    OO paradigm of system development."

    You are free to continue making absolute assertions such as "OO design is
    about behavior", but please don't expect such statements to be taken too
    seriously by experience computer professionals.

    --
    "If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true." - Bertrand
    Russell
     
    Steven T. Hatton, Nov 8, 2004
    #19
  20. Stuart Gerchick

    Phlip Guest

    Phlip, Nov 8, 2004
    #20
    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. Cindi Jenkins

    Rules Engines - Best Practices?

    Cindi Jenkins, Nov 29, 2004, in forum: Java
    Replies:
    8
    Views:
    1,295
    Edward G. Nilges
    Dec 6, 2004
  2. Otto Wyss
    Replies:
    0
    Views:
    376
    Otto Wyss
    Jun 8, 2004
  3. Trent Mick

    Coding Standards (and Best Practices)

    Trent Mick, Apr 26, 2005, in forum: Python
    Replies:
    3
    Views:
    364
    Sylvain Thenault
    Apr 27, 2005
  4. John Dalberg
    Replies:
    3
    Views:
    583
    samuelhon
    Nov 16, 2006
  5. Replies:
    0
    Views:
    409
Loading...

Share This Page