best practices

[Phlip]

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".)

 

[Tomás]

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

 

[Phlip]

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

Why?

 

[Tomás]

Phlip posted:

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

 

[Daniel T.]

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."

 

[Phlip]

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?

 

[Noah Roberts]

Phlip posted:


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.

 

[Daniel T.]

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.

 

[Noah Roberts]

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.

 

[Phlip]

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!