How we change what others think, feel, believe and do

| Menu | Quick | Books | Share | Search | Settings |

C Style: Standards and Guidelines (contents)

CHAPTER 11 : Implementing Standards


CHAPTER 11 : Implementing Standards
11.1 Raising awareness of the need for standards
11.2 'Disadvantages' of coding standards
11.3 Getting the standards defined
11.4 What should the standards contain?
11.5 Getting the standards into use
11.6 Prove the value
11.7 Keeping the standards alive
11.8 Making sure the standards are used
11.9 Summary

<--Prev page | Next page -->


11.2  'Disadvantages' of coding standards

There are a number of criticisms used to declaim coding style standards, pointing out the disadvantages, without considering the advantages described above. In each case, there is always a reasonable response:


Criticism: The 'imposition' of standards removes the 'creative' element of programming.

Response: The creative element in programming is more in the design, than in the coding. All but the most stringent standards and the most detailed designs leave plenty of creative scope for the coder. The only creativity that is to be frowned on is that which adds unnecessary complexity to the code.


Criticism: Standards force people to change their methods which are perfectly alright as they are.

Response: It's true. If a group of people are to use a common standard, then most people will have to change their ways. It is also commonly true that the people who are least willing to change are those who suffer most when looking at other people's code (and when converted to the new standards, they become its most ardent supporters).


Criticism:  Standards reduce productivity by forcing unnecessary actions.

Response: If a programmer considers it unnecessary to comment his code, then this may be true. In any case, the actual time spent typing code is a small proportion of the total time programming effort. Also the increased testability, maintainability, etc. of the code makes the overall productivity much higher.


Criticism: Standards do not prevent bugs.

Response: Using standards means that some of the less creative coding tasks are more mechanical - this gives more time for thinking about getting the rest of the program right. Writing comments and devising 'meaningful' symbol names means considering how the program can be explained to someone else - this is also a good way of spotting problems.


Criticism:  That point of style is just the current fashion.

Response: Fashions are introduced for emotional, not logical reasons. They are characterized by being temporary - being replaced by the next fashion. However, most points of style that are accused of being 'fashionable' are often a change for a specific logical purpose. The acid test is whether there is a fair and logical argument for using the debated point of style.


Criticism:  "You can lead a horse to water, but you can't make it drink." The imposition of standards does not mean that people will actually use them.

Response: 1. Don't impose, implement! This means involving the people who will use the standards in their definition, thus promoting 'ownership' amongst the user community.
2. Start by selling to the leaders, the others will follow more easily.
3. Police usage of the standards in code reviews and inspections (another good practice!).
4. If a standard isn't used, then it probably isn't very good (for your organization, at least).


<--Prev page | Next page -->


Site Menu

| Home | Top | Settings |

Quality: | Quality Toolbook | Tools of the Trade | Improvement Encyclopedia | Quality Articles | Being Creative | Being Persuasive |

And: | C Style (Book) | Stories | Articles | Bookstore | My Photos | About | Contact |

Settings: | Computer layout | Mobile layout | Small font | Medium font | Large font | Translate |


You can buy books here

More Kindle books:

And the big
paperback book

Look inside


Please help and share:


| Home | Top | Menu |

© Changing Works 2002-
Massive Content -- Maximum Speed