[vtk-developers] vtk Coding style : Proposed change

[Mathieu Malaterre]

Hi John,

> I have a number of modules that I would like to (and have been asked to) 
> contribute in the near to mid-term future but I do not wish to reformat 
> my code to fit the vtk coding style. If (for example) vtkNetCDFReader is 
> contributed to vtk/paraview, I will most likely be doing the majority of 
> maintenance and fixing work on the class(es). I do not like the vtk 
> coding style as I find it hard to quickly mentally parse (bracket 
> indentation in particular) and I would like to reserve the right to use 
> my own coding style on the contributed class(es). I can digest and debug 
> my own code considerably faster because I am familiar with the way it is 
> structured and laid out.

	Thanks a lot for your contribution ! As always this is extremely 
appreciated.
	Just a few things.

#1. VTK is ~1000 classes. For more than 10 years it manages to keep an 
very consistent coding style. This is extremely easy to edit one class 
as every one looks alike.

#2. kwStyle will soon be used on VTK on a nightly basis. As far as I 
understand this will make sure that coding style is indeed consistent.

#3. Keep in mind that VTK is at the same time an open source project 
where anyone -well almost- can contribute too. But on the other hand 
Kitware *is* doing support for anything into VTK. Maybe I am speaking 
for myself, as I am doing a lot of support work. But I will be very 
disappointed if I ever have to support your contribution and discover I 
can not easily read it.


	To follow up on David's comments:

2) Use of "this->" in front of ivars: yes, it's verbose, but it avoids 
confusion and helps me visually parse the code a lot faster.

	The 'this->' notation IMHO should be compulsory (C++ standard!). Anyone 
that have been using template knows how much this is important. Thus if 
we have to use, then why not use it consistently in the project.

3) Consistent use of lower case for first character of parameter and 
local variable names, consistent use of upper case for ivars and methods.

	Exact same problem. If you don't use 'this->' and declare a local var 
with a capital letter, I have to admit that I am already lost. This is a 
member variable for me, no doubt...

For 1) (vtk prefix for functions) this is a technical issue more than a 
coding style. I am more a namespace guy, than a prefix guy.

For 4) This is completely automated process. I am hoping that there is a 
way to automate that. ~80 chars is great when you have to compare two files.

Regards,
Mathieu