Recent Forum posts have raised discussion about what is Best Practice. There are 2 opposite views that must be reconciled. Firstly we all know that some code constructs for example are just wrong – always in every circumstance. Secondly we all recognise that what is best differs between organisations and between projects even. How do we account for both (correct) views ?
Firstly we should distinguish between Standards and Guidelines
Normally these roll off the tongue together so closely that we think of them as a compound noun as in “Let’s blow the dust off our S&G document” but they are really different things.
Standards should be rules that are accepted as definitive by developers. If they are broken by a new piece of code then that code should fail code review. Ideally the Standards document should be boiled down to a single piece of paper with bulleted rules that are universally accepted by the developers.
Guidelines are just that; principles of what constitutes good code with examples of how to achieve certain types of functionality. As such Guidelines only really apply to new development to help get past the ‘blank sheet of paper’ syndrome.
Secondly we should understand that even within an organisation different sets of Standards should apply in different circumstances – Legacy Code, Business as Usual Code and Moving Forward Code.
Every (almost?) organisation has some Legacy Uniface code. If this was written in an older version then it will have used S&G appropriate to that version which may have been superceded over time. If it is necessary to modify this code it would be pointless (dangerous) to retrofit S&G from newer versions. In this case the new development should employ the old idioms and be judged against those standards.
For Business as Usual developers are adding new functionality to a system but within the existing architecture. This probably constitutes the bulk of the current development effort and is where we apply what we usually consider our ‘S&G document’
Moving Forward work is an opportunity to use newer Uniface technology within the organisation. Perhaps new components might be written to use Entity Services; new functionality might be implemented primarily in session services with a very thin front end that can be easily replaced. This Moving Forward stuff can easily be distinguished from Business as Usual and does not have to have the same standards and is certainly not going to use the same Guidelines.
Of course over time the Moving Forwards S&G become Business as Usual and the Legacy code will gradually be replaced. The point is that S&G have to be fluid and can come in different flavours at any point in time within an organisation.
Whether or not they are stated explicitly there are always some fundamental principles that underlie a set of S&G. Depending on how they are phrased they might be – “Minimise bugs at Source” or “Maximise Maintainability” or whatever. Most developers would probably consider consistency to be an important aspect of best practice but this is really consistency in context.
The need for consistent style within a component is obvious but consistency should not hinder the vital evolution of Guidelines over time. Standards probably change more slowly as they should be a very short conservative list of ‘unbreakable’ rules but it is still important to recognise that they do change and to be comfortable with supporting legacy code that breaks current standards.
There are 3 interesting forum topics that could hang off this:
- What are the fundamental principles that should be the basis of best practice ?
- What are the universally accepted standards that ALL Uniface code should adher to ALL the time (are there any?)
- What are the current bleeding edge pieces of Uniface technology that require (better) guidelines ?
(Just something I wanted to get off my chest – if this is obvious then fine; if it is controversial even better!)