>Len
>
>>What I've tended to do in the past (especially for new projects) is to use a set of guidelines of (best ?) practices that should be applied to the particular project. Ideally, all coding/documentation/etc will adhere to these guidelines, but if the programmer finds it necessary to go against the guidelines & can justify to me (& the rest of the team - I have occassionally been known to be democratic) why the guidelines should not be used, then I will accept it.
>
>Having individual guidelines for each project is a bit much, isn't it?
>
>Surely it doesn't effect the outcome of the project if a developer has to change their practices on each new project? Unless you are talking about the look and feel of things like the UI.
>
>Kev
It all depends on the projects, if all of your projects are similar, then you probably don't need different sets.

With much of the work I have been involved with, for a large variety of different customers & a large variety of applications, it was more appropriate to have different sets of guidelines. I have had to use a variety of types of computer from microprocessor system through PCs to mini's & PLC's, different operating systems & different programming languages - low & high level.

In at least one case, the actual programming style & instruction set used, were not specified because they were either the 'best programming practice' or most efficient method (in terms of speed or code size), but because the system had to run in parallel with an existing system & had to be maintained & modified by the clients own engineers. In that case the appropriate 'best practice' was not what would have been appropriate for creating a new system or one that we would be maintaining.