Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!njin!princeton!udel!mmdf From: eric@cs2.wsu.edu Newsgroups: comp.os.minix Subject: Re: Reposting of "style" message Message-ID: <6139@louie.udel.EDU> Date: 27 Dec 88 16:54:55 GMT Sender: mmdf@udel.EDU Lines: 74 Andy Tanenbaum write: > 1. Function types (e.g., struct inode *) are written on the same line as the > function name. The reason for putting the function name on its own line is that you can then do "/^" in an editor like vi to find the definition of a function. It is much more difficult to have to remember the type the function returns (and also how it was spaced). Of course, tags are used for this, but sometimes it's just easier to do a search. > 2. No spaces before or after parentheses in functions or calls. This (and many below) are quite difficult for a beautifier without doing a fairly complete parse of the input source. The purpose of 'cb' as I understand it is not to do such a parse, but rather to adjust mostly indentation. > 4. Each is described by a short comment starting at tab stop 4 (col 33). > 6. Each function starts with a comment in the form of one or more complete > sentences. Multiline comments all contain vertically aligned asterisks. > 7. Include a blank line after the initial comment. I don't feel that commenting style has any place in a C beautifier. > 8. All declarations come next. No inner declarations, e.g. {int x; ...}. Are you implying that a particular style of programming should preclude the use of the full language? > 10. Initial indentation is two spaces. Subsequent indentation is at tab stops. > This reduces the chance of exceeding 80 characters on a line. Any C beautifier which is worth anything will make the number of spaces to indent blocks a parameter. > 12. Short if statements are included on a single line. Short? How Short? Well, it looks to me like Andy is making a case more for programming style than program code format. Despite what may look like critical comments up above, I generally approve of the format used throughout the MINIX code. Unfortunately, not everybody is going to. In a real commercial environment where we were all getting paid by Andy to play with MINIX, it would be quite reasonable to impose such restrictions (guidelines) on code format. But, MINIX is not a commercial product (though it is copyrighted) and many of us work on MINIX just for the joy it gives to get a program to do what you want. For the MINIX code itself, it is reasonable to maintain a rigid format across all functions and files. This makes the code easier to follow. However, it is becoming obvious that there is much more to MINIX than the code for the OS itself. For the code which people contribute, it is ridiculous to require a particular format. I would like to see any attempts at a C beautifier. I think that the ones which will be most useful will be those that are the most flexible. How about a table driven systems similar to 'termcap' or 'printcap' or 'vgrindefs' which allows each person to tailer the output to there own taste? Of course, mine is not the only opinion, but I don't think it is right for a C beautifier to be moving comments or code to any significant degree. Perhaps some kind soul out there will volunteer to write a nice, flexible beautifier which is written primarily in YACC and LEX (bison and flex) that can easily be modified to particular tastes. Eric Schneider (eric@wsu.edu)