[Nipy-devel] [nipype] Semantics [was] Naming convention for FSL interfaces

Christopher Burns cburns@berkeley....
Wed Jan 27 17:10:31 CST 2010


On Wed, Jan 27, 2010 at 9:01 AM, Satrajit Ghosh <satra@mit.edu> wrote:
> i took chris' email to address some semantics issues. i think this is a
> general aspect that we will need to address soon and perhaps with a sprint.
> i believe this is also what dav was referring to in regard to the interfaces
> api.

Great point Chris, thanks for bringing it up.  I think this is a
perfect thing to sprint on.  We discussed having a few sprints before
our next release, lets have one next week.  Actually, how about having
one each week for the next three weeks and we'll release mid-February?
 I know schedules are busy, if we have three sprints, hopefully we can
schedule them so that everyone can participate for a few hours on at
least one sprint.  If developers agree I'll share the nipy google
calendar and work out a schedule?

Some items to sprint on:
- class and functions names conform to PEP008 standards.
- better test coverage
- documentation, fix current build warnings, improve docs in general
- bug fixes, close some tickets

Basically, no new functionality, but some thorough cleaning and
improved code quality in general.

> 1. other than following Python conventions, i would also like to note that
> FSLsmooth and FSLmath are sort of redundant when we say:
> from fsl import FSLmath or fsl.FSLmath. i would like to get rid of FSL
> altogether. a lot of this is historical  and part of the tussle here is that
> we would like to reflect underlying command and i/o names of the interface
> (e.g., fslsplit, fslroi) and we often fall prey to using their terms even
> when there may not be a good reason. i think we have a sufficient bulk of
> functionality now that we should start being consistent with every new
> function we add.

+1 on conforming with the Python naming conventions.

> 2. invol, infile(s), smoothedimages, outvol, outfile - we have every
> possible naming convention there is for input and output parameters. we
> should settle this as well (soon). we need to keep in mind that nipype will
> support in memory computations (in the future) as well as file-based
> computations.
>
> here is a suggested grammar for naming convention
>
> [(in|out)_]name[_type]
>
> where,
>  name is : specific (e.g., label, mask, ...) or general (e.g., vol, surf,
> txt, ...)
>  type is : file(s), obj, func, list, arr, mesh, int, float, bool, str
>
> i think 'type' may be useful, but the added verbosity may not be necessary.
> (agnostic to its inclusion)

I think having a naming convention is good, but I'd prefer a more
general then specific convention.  If we start defining variable names
with a lot of type information I believe the code will become harder
to read.  At least that was my experience with Hungarian Notation.
The docstring is the appropriate place for the type information.

I like the practicality of the Linux Kernel naming convention:

http://lxr.linux.no/#linux+v2.6.32/Documentation/CodingStyle#L237

> 3. breaking down fsl.py and other interfaces into sub packages. we've gotten
> to a stage, where some interfaces are really long files and become difficult
> to navigate. i would be in favor of breaking these down into sub-packages
> and export all of their interfaces to the top interface level.

+1


-- 
Christopher Burns
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
510-643-4053
http://cirl.berkeley.edu/



More information about the Nipy-devel mailing list