best practices

Discussion in 'C++' started by Phlip, Apr 10, 2006.

  1. Phlip

    Phlip Guest

    Newsgroupies:

    Good guidelines keep source code within a "comfort zone". Programming
    languages provide extraordinarily wide design spaces, much wider than
    hardware designs enjoy, with many tricks and backdoors that could provide
    hours of pleasant diversion writing obfuscated code.

    Don't write like that on the job. Always write similar, obvious statements
    to do similar, simple things. Engineers learn their working vocabulary from
    experience and teammates. A healthy subset of all possible language
    constructions keeps everyone sane.

    Programming tutorials often contain recommendations like:

    * "Make all data private to a class."
    * "Program to the interface, not the implementation."
    * "No global variables."
    * "High level policy should not depend on low level detail."
    * "Declare a separate interface for each category of client to a class."
    * "No down-casting. Don't use an object's type in a conditional."
    * "Don't do too much on one line."
    * "Use return to prematurely exit nested loops."
    * "Use complete, pronounceable names."
    * "Dependencies between modules should not form cycles."
    * "Don't allow client objects to tell the difference between servant
    objects using the same interface."
    * "Don't use anObject.getSomething().getSomethingElse()... too deeply -
    tell the target object what your high-level intent is, and let it
    pass the message."
    * "Different variables holding the same datum should have the same name."
    * "Never return null. Never accept null as parameter."
    * "In C++, don't abuse #define."
    * "Put a class's public things at the top; private things below."
    * "Give identifiers the narrowest scope possible."
    * Etc...

    Such rules are hardly exalted wisdom or exact engineering constraints (and
    so is "test-first"). They are easy to remember, and nearly always preserve
    code flexibility. All these rules are infinitely debatable. Rules are meant
    to be made, followed, and broken.

    (Those curious how to follow the rule "never return null" may research a
    Refactor called "Introduce NullObject".)

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
     
    Phlip, Apr 10, 2006
    #1
    1. Advertising

  2. Phlip

    Tomás Guest

    Phlip posted:

    > Newsgroupies:
    >
    > Good guidelines keep source code within a "comfort zone". Programming
    > languages provide extraordinarily wide design spaces, much wider than
    > hardware designs enjoy, with many tricks and backdoors that could
    > provide hours of pleasant diversion writing obfuscated code.
    >
    > Don't write like that on the job. Always write similar, obvious
    > statements to do similar, simple things. Engineers learn their working
    > vocabulary from experience and teammates. A healthy subset of all
    > possible language constructions keeps everyone sane.
    >
    > Programming tutorials often contain recommendations like:
    >
    > * "Make all data private to a class."
    > * "Program to the interface, not the implementation."
    > * "No global variables."
    > * "High level policy should not depend on low level detail."
    > * "Declare a separate interface for each category of client to a
    > class." * "No down-casting. Don't use an object's type in a
    > conditional." * "Don't do too much on one line."
    > * "Use return to prematurely exit nested loops."
    > * "Use complete, pronounceable names."
    > * "Dependencies between modules should not form cycles."
    > * "Don't allow client objects to tell the difference between servant
    > objects using the same interface."
    > * "Don't use anObject.getSomething().getSomethingElse()... too deeply -
    > tell the target object what your high-level intent is, and let it
    > pass the message."
    > * "Different variables holding the same datum should have the same
    > name." * "Never return null. Never accept null as parameter."
    > * "In C++, don't abuse #define."
    > * "Put a class's public things at the top; private things below."
    > * "Give identifiers the narrowest scope possible."
    > * Etc...
    >
    > Such rules are hardly exalted wisdom or exact engineering constraints
    > (and so is "test-first"). They are easy to remember, and nearly always
    > preserve code flexibility. All these rules are infinitely debatable.
    > Rules are meant to be made, followed, and broken.
    >
    > (Those curious how to follow the rule "never return null" may research
    > a Refactor called "Introduce NullObject".)



    I rather re-learn the alphabet than read over such a document.

    -Tomás
     
    Tomás, Apr 11, 2006
    #2
    1. Advertising

  3. Phlip

    Phlip Guest

    Tomás wrote:

    >> (Those curious how to follow the rule "never return null" may research
    >> a Refactor called "Introduce NullObject".)

    >
    > I rather re-learn the alphabet than read over such a document.


    Why?

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
     
    Phlip, Apr 11, 2006
    #3
  4. Phlip

    Tomás Guest

    Phlip posted:

    > Tomás wrote:
    >
    >>> (Those curious how to follow the rule "never return null" may

    research
    >>> a Refactor called "Introduce NullObject".)

    >>
    >> I rather re-learn the alphabet than read over such a document.

    >
    > Why?
    >


    I was referring to the overall idea of "Good practise code". I've been
    programming long enough to take my own advice.

    When I hear something like "don't use global variables", I don't even
    laugh, I just tune out.


    -Tomás
     
    Tomás, Apr 11, 2006
    #4
  5. Phlip

    Daniel T. Guest

    In article <Y2z_f.3245$>,
    Phlip <> wrote:

    > Newsgroupies:
    >
    > Good guidelines keep source code within a "comfort zone". Programming
    > languages provide extraordinarily wide design spaces, much wider than
    > hardware designs enjoy, with many tricks and backdoors that could provide
    > hours of pleasant diversion writing obfuscated code.
    >
    > Don't write like that on the job. Always write similar, obvious statements
    > to do similar, simple things.


    The best part about following the above advice is that it makes it easer
    to find abstractions. Looking for ways to make two bits of code look the
    same goes a long way toward finding new abstractions to exploit.

    > Engineers learn their working vocabulary from
    > experience and teammates. A healthy subset of all possible language
    > constructions keeps everyone sane.
    >
    > Programming tutorials often contain recommendations like:
    >
    > * "Make all data private to a class."
    > * "Program to the interface, not the implementation."
    > * "No global variables."
    > * "High level policy should not depend on low level detail."
    > * "Declare a separate interface for each category of client to a class."
    > * "No down-casting. Don't use an object's type in a conditional."
    > * "Don't do too much on one line."
    > * "Use return to prematurely exit nested loops."
    > * "Use complete, pronounceable names."
    > * "Dependencies between modules should not form cycles."
    > * "Don't allow client objects to tell the difference between servant
    > objects using the same interface."
    > * "Don't use anObject.getSomething().getSomethingElse()... too deeply -
    > tell the target object what your high-level intent is, and let it
    > pass the message."
    > * "Different variables holding the same datum should have the same name."
    > * "Never return null. Never accept null as parameter."
    > * "In C++, don't abuse #define."
    > * "Put a class's public things at the top; private things below."
    > * "Give identifiers the narrowest scope possible."
    > * Etc...
    >
    > Such rules are hardly exalted wisdom or exact engineering constraints (and
    > so is "test-first"). They are easy to remember, and nearly always preserve
    > code flexibility. All these rules are infinitely debatable. Rules are meant
    > to be made, followed, and broken.


    These rules are much like what "The Little Brown Handbook" is to English
    composition. When writing in any language, there are many ways to say
    the same thing. Some are more creative, while some are more proper.

    Our goal should be to write "proper" C++, which is much more restrictive
    than simply "it compiles and the result is correct."


    --
    Magic depends on tradition and belief. It does not welcome observation,
    nor does it profit by experiment. On the other hand, science is based
    on experience; it is open to correction by observation and experiment.
     
    Daniel T., Apr 11, 2006
    #5
  6. Phlip

    Phlip Guest

    Tomás wrote:

    > When I hear something like "don't use global variables", I don't even
    > laugh, I just tune out.


    Did you notice the verbiage "Such rules are hardly exalted wisdom or exact
    engineering constraints"?

    If you wrote code with a team, would you expect them to adjust your style?

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
     
    Phlip, Apr 11, 2006
    #6
  7. Phlip

    Noah Roberts Guest

    Tomás wrote:
    > Phlip posted:
    >
    > > Tomás wrote:
    > >
    > >>> (Those curious how to follow the rule "never return null" may

    > research
    > >>> a Refactor called "Introduce NullObject".)
    > >>
    > >> I rather re-learn the alphabet than read over such a document.

    > >
    > > Why?
    > >

    >
    > I was referring to the overall idea of "Good practise code". I've been
    > programming long enough to take my own advice.
    >
    > When I hear something like "don't use global variables", I don't even
    > laugh, I just tune out.


    True that, but on the other hand I run into code that uses globals
    often enough to warrant reiterating the idea that they are bad. Not
    only that, but I run into such aweful constructs as globals being used
    for more than one purpose by different sections of code....shudder.

    On the other hand, I don't agree with all of the "best practices"
    listed...for instance never returning null as, in C and C++ at least,
    null is quite often used for "not found" or "unavailable" and is a
    great way to return such a concept without having to use return codes
    and output parameters or getting stuck with the quite questionable idea
    of throwing an exception for such a normal event. I don't see much
    point creating an object to represent null just to ask it if it is null
    when such an object already exists: 0.
     
    Noah Roberts, Apr 11, 2006
    #7
  8. Phlip

    Daniel T. Guest

    In article <tOC_f.8034$>,
    "Tomás" <> wrote:

    > When I hear something like "don't use global variables", I don't even
    > laugh, I just tune out.


    By all means Tomas, globals are good. In fact I kind of wonder why a
    rather large chunk of the language is devoted to limiting the scope of
    variables when globals can do it all.

    This I know, if you write a program using only globals, you are doomed
    to failure. Writing a program with no globals will (all other things
    being equal) produce a better program in every way.


    --
    Magic depends on tradition and belief. It does not welcome observation,
    nor does it profit by experiment. On the other hand, science is based
    on experience; it is open to correction by observation and experiment.
     
    Daniel T., Apr 11, 2006
    #8
  9. Phlip

    Noah Roberts Guest

    Daniel T. wrote:
    > In article <tOC_f.8034$>,
    > "Tomás" <> wrote:
    >
    > > When I hear something like "don't use global variables", I don't even
    > > laugh, I just tune out.

    >
    > By all means Tomas, globals are good. In fact I kind of wonder why a
    > rather large chunk of the language is devoted to limiting the scope of
    > variables when globals can do it all.
    >
    > This I know, if you write a program using only globals, you are doomed
    > to failure. Writing a program with no globals will (all other things
    > being equal) produce a better program in every way.


    I think Thomas was refering to the fact that the "no globals" concept
    is pretty old-hat, not that he disagreed with it.
     
    Noah Roberts, Apr 11, 2006
    #9
  10. Phlip

    Phlip Guest

    Noah Roberts wrote:

    > I think Thomas was refering to the fact that the "no globals" concept
    > is pretty old-hat, not that he disagreed with it.


    Ah, but now we have Singletons to abuse!

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
     
    Phlip, Apr 11, 2006
    #10
    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. Izvra
    Replies:
    0
    Views:
    544
    Izvra
    Dec 23, 2003
  2. news.microsoft.com
    Replies:
    0
    Views:
    545
    news.microsoft.com
    May 3, 2004
  3. karim
    Replies:
    0
    Views:
    464
    karim
    Jul 13, 2003
  4. John Dalberg
    Replies:
    3
    Views:
    574
    samuelhon
    Nov 16, 2006
  5. Chicken McNuggets

    Best book on C gotchas and best practices?

    Chicken McNuggets, Jul 31, 2013, in forum: C Programming
    Replies:
    9
    Views:
    268
    Fred J. Tydeman
    Aug 5, 2013
Loading...

Share This Page