Re: [Wxruby-dev] Naming questions

[Richard Kilmer]

Hi all...I am one the the FreeRIDE core developers...but want to throw 
in my $.02 on this...

I wrote the wrapper for the Scintilla edit controller and had to deal 
with the CamelCase -vs- underscore_notation issue...I wrote this Ruby 
function to convert them to underscore from Camel:

  def un_camelcase(func)
    result = ""
    scratch = ""
    func.each_byte do |byte|
      if (?A..?Z).include? byte
        scratch << byte.chr
      else
        if scratch.size==1
          result += "_"+scratch
          scratch = ""
        elsif scratch.size>1
          result += "_"+scratch[0..-2]+"_"+scratch[-1,1]
          scratch = ""
        end
        result += byte.chr
      end
    end
    result += "_"+scratch if scratch!=""
    result = result[1..-1] if result[0,1]=='_'
    result.downcase
  end

The rules are:

A capital letter begins an underscore separator and if multiple capital 
letters are found they are grouped and then an underscore is inserted 
before the last capital like so:

MethodNameOne -> method_name_one
RICHIsFullOfIt -> rich_is_full_of_it
MethodISITReallyNamedThis -> method_isit_really_named_this

Also, methods that return a c/c++ based boolean (1 or 0) I change to 
return a Boolean (true or false) and the method is appended with a 
question mark (?)...which is a ruby convention for boolean return 
methods:

IsThisYourMethod -> is_this_your_method?

Anyway...that is what I used.

BTW: Class names should be CamelCase...and constants are normally 
FULLY_CAPITALIZED.

Thanks for efforts to move this project along...we in the FreeRIDE 
group are looking forward to using it (and getting it to work under OS 
X :-)

Rich

On Sunday, May 25, 2003, at 04:40  PM, Kevin Smith wrote:

> So, when we wrap the original wxApp::SetAppName which of these do you
> think it should be?
>
> SetAppName
> setAppName
> set_app_name
>
> Personally, I prefer setAppName, which is consistent with our inversion
> of the first letter of all the class names, from wxApp to WxApp.
>
> But what should we do with current methods like EVT_ACTIVATE?
>
> EVT_ACTIVATE
> evt_activate
> evt_ACTIVATE (ugh)
> eVT_ACTIVATE (UGH)