As a pragmatic uniface methusalem coder, I read it as follows:

STANDARDs: codeblocks, frameworks, templates which I can copy without thinking (because "when in rome, do as the romans do").

GUIDELINEs: mandatory instructions how to act in a given situation ("if fallen in a river, start swimming immediately")

BEST PRACTICEs: a collection of "ways to handle the context" I can learn from for my situation.

What we need are THINK FIRST people who know
how to use the tool "uniface" in a given context,
not "dedicated followers of fashion".

Success, Uli

Uli,

sorry to be pedantic but

• 'Standards' are Rules that must be obeyed - they can change but only as part of a managed process. 

They should be as brief as possible in order to become part of the developer instinctive style.

• 'Guidelines' are the samples, rules of thumb etc. that suggest ways of doing certain things especially when breaking new ground. 

Guidelines are a much bigger document or set of documents than standards - they are not meant to be memorised

• Best practice is a combination of sticking to standards and following guidelines and having a ongoing process for managing both.

Thanks

Hi Andrew,

agree with you on the theoretical part of S&G,
but as "pragmatic developer"
it matters how these support/affect my daily practical work.

"Instinctive style" implies some learning curve,
but newbies/temps/freelancers have to be able to follow the standards from day one onwards.

5 folders "Standards" does not help a lot
if they are not transformed in templates , building blocks, automatisms, (workflows?).
Because developers like us are keen to get rid of "silly" code-typing
good codeblocks are "the bait" to make standards reality by using the artifacts.

For me as an acting codewriter, Guidelines are the things one should follow ("that's the way WE do it"),
but can not expressed in real artefacts, "GUI style guides" are in that category. 

The sticking to standards and following guidelines and having a ongoing process for managing both
are in one part "project reviews" and "lessons learned"

In contrast to the internal-only, "Best practices" are stories 
happened in the outside world and perhaps in your project .

In most cases, there is
a brief description of the context
and the way a task was completed,
some rationales
and background info may complete this story.

Just read them and decide if this inspires your way of doing thins.

Success, Uli

if it's friday eve and you have nothing to do ..

a very interesting 1hr video about the different aspects of "making people work better"
can be found at www.infoq.com/presentations/coaching-scaling-agility

Success, Uli

This is a quote from:C++ Exceptions: Pros and Cons

From a "glass half full" point of view, with exceptions or without them C++ has always been an expert-friendly language that offers very little hand-holding to beginners. Rather than relying on the constraints of the language a good C++ programmer turns to the community to teach him the best practices of using the language. The guidelines from the community change faster than the language itself: someone who switched from C++ to Java in 1997 often gets very confused when presented with modern C++ code - it looks different, yet the language itself had not changed much. Back to the exceptions, the C++ community learned a lot on how to effectively use them since they were first introduced to the language; someone who follows new publications and newsgroups should pick up the best practices with some effort.

Is the situation in unifaceland not similar to that beside there is by far not such an active community helping each other.

SUccess, Uli