22 Sep 2020 23:42:16 UTC
- Distribution: Devel-FIXME
- Module version: 0.02
- Source (raw)
- Browse (raw)
- How to Contribute
- Issues (0)
- Testers (107 / 3 / 0)
- KwaliteeBus factor: 1
- 81.57% Coverage
- License: perl_5
- Perl: v5.8.0
- Activity24 month
- Download (11.8KB)
- MetaCPAN Explorer
- Subscribe to distribution
- This version
- Latest version
- DECLARATION INTERFACE
- OUTPUT FILTERING
- VERSION CONTROL
- COPYRIGHT & LICENCE
- SEE ALSO
Devel::FIXME - Semi intelligent, pending issue reminder system.
this($code)->isa("broken"); # FIXME this line has a bug
Usually we're too busy to fix things like circular refs, edge cases and so forth when we're spewing code into the editor. This is because concentration is usually too valuable a resource to throw to waste over minor issues. But that doesn't mean the issues don't exist. So usually we remind ourselves they do:
... # FIXME I hope someone finds this comment
and then search through the source tree for occurrances of FIXME every now and then, say with
grep -ri fixme src/.
This pretty much works until your code base grows, and you have too many FIXMEs to prioritise them, or even visually tell them apart.
This package's purpose is to provide reminders to FIXMEs (without the user explicitly searching), and also controlling when, or which reminders will be displayed.
There are several ways to get your code fixed in the indeterminate future.
The first is a sort-of source filter like compile time fix, which does not affect shipped code.
$code; # FIXME broken
That's it. When Devel::FIXME is loaded, it will emit warnings for such comments in any file that was already loaded, and subsequently loaded files as they are required. The most reasonable way to get it to work is to set the environment variable PERL5OPT, so that it contains
-MDevel::FIXME. When perl is then started without taint mode on, the module will be loaded automatically.
The regex for finding FIXMEs in a line of source is returned by the
regexclass method (thus it is overridable). It's quite crummy, really. It matches an occurrance of a hash sign (
#), followed by optional white space and then
XXX. After that any white space is skipped, and whatever comes next is the fixme message.
Given some subclassing you could whip up a format for FIXME messages with metadata such as priorities, or whatnot. See the implementation of
The second interface is a compile time, somewhat more explicit way of emmitting messages.
use Devel::FIXME "broken";
This can be repeated for additional messages as needed. This is useful if you want your FIXMEs to ruin deployment, so you're forced to get rid of them. Make sure you run your final tests in a perl tree that doesn't have Devel::FIXME in it.
The third, and probably most problematic is a runtime, explicit way of emmitting messages:
use Devel::FIXME qw/FIXME/; $code; FIXME("broken");
This relies on FIXME to have been imported into the current namespace, which is probably not always the case. Provided you know FIXME is loaded somewhere in the running perl interpreter, you can use a fully qualified version:
or if you feel that repeating a word is clunky, do:
$code; Devel::FIXME->msg("broken"); # or $code; Devel::FIXME::msg("broken");
But do use the first FIXME declaration style. Seriously.
There are some problems with simply grepping for occurances of FIXME:
It's messy - you get a bajillion lines, if your source tree is big enough.
You need context. While grep can provide for it, that isn't necessarily simple to read.
You (well I do anyway) forget to do it. And no, cron is not really a solution.
The solution to the first two problems is to make the reporting smart, so that it decides which FIXMEs are printed and which arent.
The solution to the last problem is to have it happen automatically whenever the source code in question is used, and furthermore, to report context too.
The way FIXMEs are filtered is similar to how a firewall filters packets.
Each FIXME statement is considered as it is found, by iterating through some rules, which ultimately decide whether to print the statement or not.
This may sound a bit overkill, but I think it's useful.
What it means is that you can get reminded of FIXMEs in source files that are more than a week old, or when your release schedule reaches feature freeze, or if your program is in the stable tree if your source management repository, or whatever.
There are many modules that know how to parse SCM meta data, for CVS, Perforce, SVN, and so forth. File::Find::Rule can be used in nasty ways to ask questions about files (like was it modified in the last week?). The possibilities are quite vast.
Currently the FIXMEs are filtered by calling the class method
rules, and evaluating the subroutine references that are returned, as methods on the fixme object.
The subclass Devel::FIXME::Rules::PerlFile is a convenient way to get rules from a file.
- FIXME's magic sub is no longer first in @INC
requireis called and the @INC hook is entered, it makes sure that it's first in the @INC array. If it isn't, some files might be required without being filtered. If the global variable
$Devel::FIXME::REPAIR_INCis set to a true value (it's undef by default), then the magic sub will put itself back in the begining of @INC as required.
If I had a nickle for every bug you could find in this module, I would have
$nickles >= 0.
- The regex for finding FIXMEs is stupid.
It will find FIXME's in a quoted string, or other such edge cases. I don't care. Patches welcome.
This module is maintained using Darcs. You can get the latest version from http://nothingmuch.woobling.org/Devel-FIXME/, and use
darcs sendto commit changes.
Original Author: Yuval Kogman,
Current maintainer: Nigel Horne,
Copyright (c) 2004 Yuval Kogman. All rights reserved This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.