Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > best practices

Reply
Thread Tools

best practices

 
 
Phlip
Guest
Posts: n/a
 
      04-10-2006
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!!!
 
Reply With Quote
 
 
 
 
Tomás
Guest
Posts: n/a
 
      04-10-2006
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
 
Reply With Quote
 
 
 
 
Phlip
Guest
Posts: n/a
 
      04-10-2006
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!!!


 
Reply With Quote
 
Tomás
Guest
Posts: n/a
 
      04-11-2006
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
 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      04-11-2006
In article <Y2z_f.3245$(E-Mail Removed)> ,
Phlip <(E-Mail Removed)> 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.
 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      04-11-2006
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!!!


 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      04-11-2006

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.

 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      04-11-2006
In article <tOC_f.8034$(E-Mail Removed)>,
"Tomás" <(E-Mail Removed)> 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.
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      04-11-2006

Daniel T. wrote:
> In article <tOC_f.8034$(E-Mail Removed)>,
> "Tomás" <(E-Mail Removed)> 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.

 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      04-11-2006
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!!!
 
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
Best Codeplex sample for showing best coding practices? John Dalberg ASP .Net 3 11-16-2006 12:07 PM
Application Folder Organization (Best Practices) Digital ASP .Net 0 06-29-2005 04:54 PM
Re: Best Practices - VSS integration with VS.NET, migrating our Classic ASP projects news.microsoft.com ASP .Net 0 05-03-2004 08:29 PM
best practices using procedure attributes Izvra ASP .Net 0 12-23-2003 09:43 PM
Best sample app for learning best practices, OO & asp.net? karim ASP .Net 0 07-13-2003 04:26 AM



Advertisments