In article <[EMAIL PROTECTED]>, James R. Van Zandt <[EMAIL PROTECTED]> wrote: >Stephen Zander <[EMAIL PROTECTED]> writes: >> >> Remember that the person who is most qualified to test any >> >> piece of code is the person who wrote it. >> Wichert> I can argue about that. But I won't :) >>The person who wrote the code is almost always the *least* qualified >>person to test it. > >Thorough testing needs several viewpoints. The original programmer >may be the best one to single-step through the code, checking for >things that differ from his expectations, or things which could >cause trouble given other data.
I think that that testing isn't really about style. Style implies ways to present your code to other _human_ developers who have to read it. The C compiler doesn't care how you indent 'if' statements or where you put spaces around expressions. Consistent indentation helps the programmer-to-programmer process but does nothing for the programmer-to-compiler process. Any coding convention that can be expressed as a syntactically-equivalent algorithmic transformation of any other coding convention is probably an element of style. Testing (and quality assurance in general) is a matter of good overall technique and using effective day-to-day procedures. A typical corporation develops common internal procedures to increase its efficiency, but at the same time the initial skill and experience sets of employees sometimes differ wildly (my experience has shown much greater variation between employees in a corporation than active developers on an open-source project, IMHO because the latter group selects itself). In order for a corporation to work, its new employees have to be trained in existing procedures, and the shortest path to achieving that goal is to make everyone start life by reading a common text that contains the basic knowledge necessary to function in the group. In a software shop, that common text tends to be the best known document available among the developers -- which often starts life as a coding style document. The role of this text gets expanded to include some of everything else a new employee needs to know, and it relies on knowledge that anyone who was not part of the corporation wouldn't necessarily have. We've seen this here: some Debian developers have never _seen_ Hungarian notation until three days ago, but most of Corel's developers have fingers that type "lpsz" without requiring conscious thought from nearly a decade of practice. On the other hand, some Corel developers are likely to have a really hard time setting their tab stops back to 8 characters for the first time in as many as 10 years, and anyone who has to work on both Corel and non-Corel code is going to be screaming epithets near release deadlines. I guarantee it. Open-source projects have less in common, and as such they have documents targeted toward different audiences. Part of the problem with the original set of alleged "Corel Linux" guidelines, aside from some of its contents, was that it was a witches' brew of elements of style, technique, and procedure, with not enough of any of those and too much of all of them. By contrast, the "GNU Coding Standards" is a full standards document that has style mostly separated from the technical and procedural stuff. While opinions vary about the technical content, the GNU document itself is a well organized collection of English text. All the words seem to be spelled correctly and except for the 'info' link syntax well-punctuated too. The much shorter "Linux Kernel coding style" document discusses _only_ style: indentation, placing braces, naming, function length, commenting, and using tools to adjust existing code to the correct style. It doesn't suggest any particular coding or testing techniques at all. Other Linux documents describe procedures (e.g. how to prepare and submit a patch) and technique (although defining coding technique in a kernel is always approximate at best, and sometimes actually varies by architecture). -- Zygo Blaxell, Linux Engineer, Corel Corporation. [EMAIL PROTECTED] (work) or [EMAIL PROTECTED] (play). Corel may disagree with my opinion (above). Size of 'diff -Nurw [...] winehq corel' as of Mon May 10 17:14:00 EDT 1999 Lines/files: In 54144 / 292, Out 16700 / 154, Both 48717 / 329