Tags:
create new tag
, view all tags

Implementation Quality

A cursory glance over the code can do wonders to ensure that it is wholesome. Not a programmer? Don't worry, just mark this as unrated.

Some things to consider:

  • Does it call any functions that are not declared in TWiki::Func? If so, there is a risk that the plugin will break in the future in case TWiki internals change. The plugin writer may not be around to upgrade the plugin then...
  • Does it UseStrict? if it doesn't, it probably has bugs.
  • Does it use global variables? Global variables are bad news for mod_perl, and highly likely to hide bugs.
    Note: Global variables that are constant are OK, e.g. variables that do not depend on topic name, user name, etc.
  • Does it cause warnings to be written into the web server's error log? Perl emits those warnings for a reason, so ignoring them is a sign that there might be bugs lurking around....
  • Is it tidy? Does it delete temporary files when it's finished with them?
  • Is it secure? Can you think of any way for someone to execute a command on the server using the plugin? You might be surprised at how many plugins do....
  • Is it documented? Does the code contain explanatory comments that help you understand what is going on? Or did the programmer just leave the original EmptyPlugin comments in place, and sign all their rights away? Not a good sign frown
  • Is the documentation in sync with the code? If you see variables either in the documentation that are non-existent in the code or an wider interface with more variables then this is not nice.
  • Is it written as one monolithic perl module, or separated into logical sub modules only loaded and compiled on demand? If you see a lib/TWiki/Plugins/PluginName.pm file with more than (let's say) 300 lines of code net, then it's what we call "fat". This is not a good sign. (There are exceptions: Plugins that need to run most of the code in the initialization phase, such as the BlackListPlugin.)
  • Does it perform lots of initialization steps? If you see a big initPlugin function then this is usually a bad sign, as it's probably doing work even when it's not used.
  • Does it use preference variables to statically configure the plugin? If you see lots of getPreferenceValue()) calls in initPlugin.pm initializing variables that change very rarely, or even only once installing the plugin, then this is bad practice. Configuration variables in LocalSite.cfg are much more efficient.
    Note: This does not apply to Plugins which are designed to run on versions older than TWiki 4.

Please use the comment field to explain your rating.

-- Contributors: MartinCleaver, CrawfordCurrie, MichaelDaum, PeterThoeny, ThomasWeigert

Discussions

RE: Does it call any functions that are not declared in TWiki::Func? If so, it's very, very naughty.

I beg to differ. It is better to reuse a function in TWiki core than reinventing the wheel, maybe even incorrectly so. However, this reuse does come at a price of more work when TWiki is upgraded. For example, it took me half a year to find time to upgrade our release to Dakar and thus it took half a year to upgrade a number of plugins I had written which violated this rule (for good reason I believe, but that is no comfort for another user who wants to upgrade now).

Maybe the guidance can be changed from "very, very naughty" to "warning flag, may cause difficulties in future releases".

-- ThomasWeigert - 07 Aug 2006

Another criteria: Emits large amount of warnings into the apache error log. (Sometimes that is unavoidable due to ideosyncrsies of perl, but then one can use pragmas to avoid those warnings.) This one I would consider a sign of possible defects lurking.... Added above...

-- ThomasWeigert - 07 Aug 2006

Now that there is MoreFuncContrib, perhaps we should state it as a policy that everytime that a plugin developer needs to reach inside the Core, the function must be added o MoreFuncContrib to isolate the change

-- RafaelAlvarez - 07 Aug 2006

Good move Thomas on neutralizing above text. It's a wiki!

-- PeterThoeny - 08 Aug 2006

Is there some guidance on how to use the LocalSite.cfg for plugin configuration. I'd like to leverage that idea, but am not sure what the policies are. It would be best if there was some configuration utility, so that plugin users don't have to monkey with those settings.... An idea would be that there is some way of causing settings to show up in the configure script, as one already has to run that to deploy the plugin...

-- ThomasWeigert - 08 Aug 2006

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2006-08-08 - ThomasWeigert
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.