Revisiting naming conventions

[Stephen R. Aylward]

It seems like we should go with the stl convention.   It may seem odd to
us old folks, but if stl sets a standard that the kids are learning in
highschool, we should probably follow it.

I don't feel strongly either way.  Just giving an opinion.

Stephen

"Miller, James V (CRD)" wrote:
> 
> I guess the point is that BOTH stl and the proposed matrix library use the same convention which is
> different from ours. Furthermore the stl convention is part of the ANSI standard.
> 
> However, I am not a big fan of the stl naming convention, but I can see a benefit to being
> consistent.
> 
> -----Original Message-----
> From: Ross Whitaker [mailto:whitaker at rolle.engr.utk.edu]
> Sent: Monday, April 17, 2000 7:03 PM
> To: Insight-Developers (E-mail)
> Subject: Re: Revisiting naming conventions
> 
> ******************
> 
> The question:
> 
> "The STL naming convention is different from ours.  Should we adopt it instead?"
> 
> ******************
> 
> My first thoughts:
> 
> Suppose we do.  Then suppose we adopt yet another external library---such as a matrix library.
> Suppose
> it has another naming convention.  Do we adopt it?   What if they conflict?  Then it's impossible.
> 
> It seems we should either:
> 
>     1)  Live with different naming conventions for borrowed libraries.
>     2)  Subclass heavily used libraries/objects and make them use our naming convention.
> 
> The first one seems cleaner/easier.
> 
> Regards,
> 
> Ross
> 
> ******************
> 
> "Miller, James V (CRD)" wrote:
> 
> > At the January meeting, we decided on a coding style where class names were prefixed with itk and
> > used word capitalization, i.e. our classes are named itkImage, itkImageBase, etc.
> >
> > To support smart pointers, each class has an internal typedef named "Pointer".  So to declare a
> > smartpointer to an itkImage you would use itkImage::Pointer.
> >
> > To support generic programming and the user of iterators, the image class has typedefs
> > itkImage::Iterator, itkImage::Index and itkImage::PixelType.
> >
> > We are using two external "packages", STL and a numerics package, that use a different
> nomenclature.
> > These packages use lower case class names and underscores.  For instance, the stl vector class has
> a
> > typedef vector::interator and vector::value_type and vector::reference_type and vector::pointer.
> >
> > Therefore, itk's public interface uses one naming convention; however, under the hood, we reference
> > systems that have a very different naming convention.
> >
> > Should we consider adopting the naming conventions of STL and the numerics package for consistency
> > sake?
> >
> > There are two arguments on the table.
> >
> > 1. Using our original planned naming convention, it will be very clear what is itk code and what is
> > STL/numerics code.
> >
> > 2. Using a consistent naming convention will allow people who already know STL to get up to speed
> on
> > itk quickly (and they will not have to remap STL/itk bindings).
> >
> > If we adopt STL conventions, how far should we take it? i.e. should our classnames take the form of
> > itk_image instead of itkImage?
> >
> > We have a small enough code base now, that we can change our conventions easily.  If we wait too
> much
> > longer, it will become VERY painful to switch.
> >
> > What are people's opinions on adopting the STL naming convention (which is part of the ANSI
> > standard).
> >
> > Jim Miller
> > _____________________________________
> > Computer Graphics & Systems Program
> > GE Corporate Research & Development
> > Bldg. KW, Room C218B
> > P.O. Box 8, Schenectady NY 12301
> >
> > millerjv at crd.ge.com <mailto:millerjv at crd.ge.com>
> > (518) 387-4005, Dial Comm: 8*833-4005,
> > Cell: (518) 505-7065, Fax: (518) 387-6981
> >
> >  <<James Miller (E-mail).vcf>>

-- 
=======================================================================
Stephen R. Aylward			 http://www.cs.unc.edu/~aylward
Research Assistant Professor of Radiology		aylward at unc.edu
Adjunct Assistant Professor of Computer Science		 (919) 966-9695