[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:176 glynn]:
 > Replying to [comment:175 wenzeslaus]:
 > > If I understand correctly, we still want to use full option names for
 GRASS code (and perhaps documentation) and to advise it for user scripts.
 > Indeed.
 >
 > The main issues I see with abbreviations are:
 >
 >  1. Searching for use of an option name (grep, Ctrl+F, etc) will miss
 abbreviations.
 >
 >  2. Abbreviations make code harder to understand for people who aren't
 fluent in English.
 >
 > > In this case it would be good to have a way to proof that the full
 option names are used, something like an environmental variable
 `GRASS_FULL_OPTION_NAMES` which would switch off the advanced
 word/character matching and `renamed_options` so that only full names
 would be considered as valid.
 >
 > r63765 generates a warning if GRASS_FULL_OPTION_NAMES is set (to
 anything) and the found string isn't an exact match for the given string.

 Thanks that's good but wouldn't be better to do just the `strcmp`
 comparison (to be faster) and fail (with fatal error) which would show
 these things in tests (errors are clearly visible, warning must be
 searched for in the output). I think the primary use-case for
 `GRASS_FULL_OPTION_NAMES` is when you actually want to find the long
 options and then it is just more effective to fail. The secondary use-
 case, I can think of, is making parsing faster which is only possible if
 this check is alternative, not addition. Do you have different opinion?
 (This is not necessary to decide before the release I belief because it is
 not real API considering the use-cases.)

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