SketchUp Ruby Dos and Don'ts (Best Practices)

Jim

Please add your own "Do and Don't" recommendations for writing SketchUp Ruby code.

DO wrap your plugin in a module (namespace) to avoid clashes.
DON'T use another person's registry keys, namespaces, or attribute_dictionaries.

morisdov

The problem is you dont know who might have used what "name" , there are far too many other people out there for one to research their obvious common sence choices of keywords.

I believe its best to anticipate errors and exceptions and handle them gracefully with clear messages to the end user.

Now if there would have been somwhere a virtual pc with sketchup and most current versions of scripts installed - a report can be written for all "used keywords" - so a new plugin before release to the public could be forced to test for non violation and then added to this repository itself.
Version updates should be possible so one replaces his old version with new one.

That can have many benefits for end users downloading plugins froma single place and knowing they probably dont break each other, and latest version.

Jim

Well, my method of presenting this was probably a poor choice. Maybe I should have named the thread "SketchUp-Ruby Best Practices"

todd burch

Don't arbitrarily extend SketchUp or Ruby base classes. Subclass them with your own class, and extend your class.
Use global variables only when you have to, and then, use a unique enough name to not possibly clash with any other global variables in use.
Keep your UI.beep to yourself! (or just use it for user-anticipated feedback)
Put your contact information in your comments
Tell people what your script is for and how to use it
Version your scripts
For a better user experience, leverage WebDialogs instead of the former and very limiting UI.inputbox
Strive for cross platform support
Design for eventual translation to other languages
Check return codes and code defensively

todd burch

Don't put your plugins in the /Tools folder. Treat the Tools folder as Google's repository of scripts, and the /Plugins folder as 3rd party and personal scripts. You'll be glad you did this when you migrate to a new version of SketchUp, and you can copy all your V6 /Plugin contents** to the Vnext /Plugins folder.

** The caveat to this is while Google did better position these folders for migration (perhaps unintentionally), by moving sketchup.rb (and others) to the tools folder, there are still some Google scripts and other stuff distributed in /Plugins. We don't know what Vnext will look like yet, but I'm going to make an assumption that a COPY WITHOUT REPLACE from V6 /Plugins to Vnext /Plugins will be the protocol to take.

Todd

Jim

Great posts Todd, thanks.

Dan Rathbun

@morisdov said:

@jim said:

Please add your own "Do and Don't" recommendations for writing SketchUp Ruby code.

DO wrap your plugin in a module (namespace) to avoid clashes.
DON'T use another person's registry keys, namespaces, or attribute_dictionaries.

The problem is you dont know who might have used what "name" , there are far too many other people out there for one to research their obvious common sence choices of keywords.

NO .. it's actually easy. If you stay in YOUR namespace, you can have your Plugin module(s) be any name and they will not clash.

Then.. use the namespace nesting to construct a unique registry key:

module Author
  module Widget
  
    # Construct a registry key to save the plugin options under;
    #
    @@opt_key = "Plugin_#{Module.nesting[0].name.gsub(/(;+)/,"_")}"
    # Remove whitespace and non-word chars (just in case.)
    @@opt_key = @@opt_key.gsub(/\s+/,"_").gsub(/\W+/,"")

    # the key will be; "Plugin_Author_Widget"

  end
end

Then you can use the registry key also as a prefix for any AttributeDictionary objects that this plugin uses:

module Author;;Widget

  @@dictFlags = "#{@@opt_key}_Flags"

  # create the dictionary
  @dict = ent1.attribute_dictionary( @@dictFlags , true )

  # the dictionary will be; "Plugin_Author_Widget_Flags"

end #module

Obviously,.. you replace the word "Author" with your own namespace identifier, and choose the name of your own plugin sub-modules, and their dictionary names.