[GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
 Reporter:  martinl               |       Owner:  grass-dev@…              
     Type:  task                  |      Status:  new                      
 Priority:  blocker               |   Milestone:  7.0.0                    
Component:  Default               |     Version:  unspecified              
 Keywords:  standardized options  |    Platform:  Unspecified              
      Cpu:  Unspecified           |  
----------------------------------+-----------------------------------------

Comment(by wenzeslaus):

 Replying to [comment:32 annakrat]:
 > Replying to [comment:30 glynn]:
 > > Replying to [comment:27 annakrat]:
 > > > I will change r.colors options (raster -> rast, volume -> rast3d)
 unless someone is against, sometime soon.
 > >
 > > "raster" shouldn't be abbreviated. "volume" should probably be
 "raster_3d" (for which "raster3d" and "rast3d" are accepted
 abbreviations).
 >
 > So we then have to rename also option rast, rast3d in g.region I
 suppose, and perhaps some others. We shouldn't forget that although
 unabbreviating doesn't cause problems in the command line, python scripts
 require the full name of the command.

 I would not unabbreviate everything. Some standard widely used
 abbreviations such as `rast` or `vect` are OK I would say. Non-abbreviated
 terms should be used for less standard things such as `elevation` or
 `index`. This is a good compromise between clear readable names and overly
 long options and module calls.

 Of course in some cases unabbreviating would be quite harmless concerning
 total length of option(s), for example `rast` -> `raster` but I don't have
 an idea how badly this would work for `strds` (which I'm not comfortable
 with but I don't have a better idea).

 Also sometimes you just have to make the option name shorter by leaving
 out some words. Of course this is combined a lot with abbreviating because
 it would be not readable anyway, for example `npmin` from G7:v.surf.rst
 which has meaning ''Minimum number of points for approximation in a
 segment'', the only meaningful not shortened not abbreviated name I can
 think of is `minimum_of_points_for_approximation` which is juts too long.

 This brings me to my final point. If we unabbreviate and unshorten
 everything and we will provide a lot of different options how to
 abbreviate it then we can naturally expect that people will use it a lot
 and they will of course use different abbreviations. But this, I think,
 defeats the purpose of unabbreviated option that is readability (and auto-
 documentation) because by looking at the command with abbreviated option
 you are not able to say what they mean.

 Therefore, I think that using the abbreviations occasionally on places
 where everybody would like to shorten anyway is the way to go.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:34>
GRASS GIS <http://grass.osgeo.org>