Webform vocabularies

You have nested directories that you should get rid of. The main branch of your project should only be the module files (not the module directory itself). In this case, the only files that should be available on your repo should be .info and .module, with no parent directories.

You may include subdirectories if you need them, such ass css, js, images, includes, etc.

Automated Review

Due to the structure of the current repo, automated review will not run.

Manual Review

Your function comments should follow Doxygen style formatting. See Doxygen and comment formatting conventions

Code Style (I am not as thorough as the automated review, but I am seeing some)

• Tabs should be replaced with two spaces
• Operators should have a space between the operator and the next statement: " " + " " + $value
• Statements should have a space after the opening control word and between the closing parenthesis and opening bracket
  

  if($condition){}
  // should be this:
  if ($condition) {}
  

• Don't leave whitespace characters at the end of a line
• All array entries should have a trailing comma even if it's the last item in an array
• Try to limit lines to a maximum of 80 characters as this increases readability. Not all lines need to follow this requirement, however.

webform_vocabularies_menu
- You do not need to specify an access callback if you are using user_access, as it it defaulted to that unless otherwise inherited from the parent menu item.

webform_vocabularies_admin_settings
- No need to store the return form of system_settings_form and then just return it; just return it right away:

  return system_settings_form($form);

webform_vocabularies_webform_select_options_info
- You don't need to run an additional boolean check if the vocab is an object or not, as taxonomy_vocabulary_load returns FALSE if it cannot load the object:

$vocab = taxonomy_vocabulary_load($vid);  
if ($vocab !== FALSE) {
}

With that said, there is a discussion being had as to how much code is required to allow for the vetted git user access. The general consensus is that anything with less than 120 lines of code or less than 5 functions cannot be seriously reviewed. However, we can promote this single project manually to a full project or - if possible - you can try to add more functionality/code to this one. Possibly add the ability for certain users to bypass this restriction, or add the functionality to allow certain vocabularies to webforms if they are attached to specific content types, etc (these are just random ideas, whether or not they work or are usable is neither here nor there :)).

Another link you can check out: Coding Standards.