[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:82 glynn]:
 > Replying to [comment:80 wenzeslaus]:
 > > I'm for explicit long descriptive option names but if it creates more
 issues then it solves (`3draster`) and if everybody would be using the
 shortened version all the time anyway (`rast`, ...), I prefer not to
 change them.
 >
 > Code should always use the full name. Abbreviations are intended for
 interactive use.

 This is what I mean. If we want better interactive use, let's improve it
 but not at expense of writing the code. (`3draster` is improvement for
 interactive use but it makes code worse by requiring `_3draster`.)

 As I said before, short options are mostly advantageous for unix-like
 command lines, so let's use what it used there, the Tab key auto-complete.
 This is definitively not an obsolete thing, for example Git is using it
 extensively, SVN supports it too.

 Another solution for abbreviating `raster` and `raster3d` which solves the
 problem at the level of abbreviating and does not make the code worse
 (although it might harm a little bit) is changing the ambiguity rules as
 [comment:75 Glynn suggested in comment 75]. My first impression from
 shortening actually was that it counts matching letters for each option
 and gives a best match. But this is not (unlike Tab key auto-complete)
 completely isolated from calling the modules from some code, so I'm afraid
 of two things. First, that it can become dangerous for people not using
 the long options in the code (e.g. for compatibility reasons). Second,
 that the option matching can become so costly that it would actually make
 module calls more expensive.

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