[vtk-developers] style : Holiday greetings and a present of V TK4.0

[Volpe, Christopher R (CRD)]

|> Changing the coding style now would be a pain... actually filtering
|> all the files into a new style wouldn't be too bad, but cvs 
|> diffs between
|> the pre- and post-filtered files would be meaningless.  The VTK code
|> style isn't the one that I would have chosen, but I don't 
|> have any major
|> gripes with it either.

I have one gripe, of a practical nature, and it's not the fault of the coding style but rather a
fault of MSVC++ (though not strong enough to outweigh the advantages of using it): The coding style
demands that braces that delimit function bodies *not* be indented, but other braces *should* be
indented. Like this:

void voo()
{
  if (bar)
    {
    do_something();
    }
  else
    {
    do_something_else();
    }
}

Unfortunately, VC++ only permits you to choose indented or not-indented, globally. So I indent my
function braces as well. If anyone knows how to fix this, or to fix the way VC++ screws up the
indentation on "do {...} while();" loops, let me know.


|> How about a ban on
|> > tab characters or a consistent approach to their use. Use 
|> spaces for god's
|> > sake, they are always the same size.
|> 
|> A good idea, but a little hard to enforce.

Are there any editors that don't allow you to say "turn tabs into spaces"? I configured VC++ for this
and it works fine. I don't remember off the top of my head how to do it in Xemacs, though. But there
isn't anything that can't be done in Xemacs, so I'm sure there's a way.

|> I agree with you here: I really like the
|> if (condition) {
|>   do something;
|> }
|> style because it saves space and tightly connects the 'do 

I used to like this for years because of the space saving, but that was back when my screen
resolution was 1024x768. I prefer the symmetry of having the open brace at the same column as the
closing brace. And a missing opening brace at the end of the line doesn't stand out as much as it
does when it's supposed to be on it's own dedicated line and it isn't there. And when the compiler
tells you that you've got one too many closing braces, 500 lines later, there's a certain advantage
for being able to spot these problems easily. So nowadays, with my 1600x1200 video card and monitor,
I prefer to sacrifice a few extra source lines for the sake of readability.

|> 
|> I also agree that generally
|>  - more code per screen is better
|> but I would also add
|>  - less code per line is better

These two, together, imply more physical lines per screen. This, of course, is independent of coding
style and is satisfied only by better video cards/displays. :)

|> But I still believe that the VTK code style should be left as is,
|> I've adapted to it and I don't mind it.

I agree.

|> 
|> > Major Objection 2:
|> > Line length. In the days when hairless deviants sat poring 
|> over terminals
|> > connected to a vax mainframe via a PAD line and had green 
|> screens with a 40
|> > character width, it was reasonable to restrict line 
|> lengths. But these days
|> > with super scrolling gui editors and fast searching 
|> clickety click mouse
|> > control, hot keys, bookmarks and all the other modern 
|> conveniences, I for
|> > one do not believe that it's necessary to have 40chars max 
|> on a line.

I agree. Let's up it to 80 chars. My card punch supports 80 chars, so this will be no problem for me.
:-)


> Chris
> 
============================================
Christopher R. Volpe
Computer Scientist
Visualization and Computer Vision Program 
Electronic Systems Laboratory
Bldg KW, Room C215
General Electric Corporate Research & Development
P.O. Box 8, Schenectady, NY 12301

(518) 387-7766, Dial Comm: 8*833-7766, Fax: (518) 387-6981
e-mail: volpecr at crd.ge.com    web: http://www.crd.ge.com/~volpecr