More about Regular Expressions (REs), which can be safely ignored by those not interested ... -- www.macfh.co.uk/MacFH.html
> > it might be necessary to bracket it at the beginning and end with > > non-capturing non-word meta- or pseudo-characters > > Rather than \W, representing a single non-word character, \b would be > better, meaning a zero-width boundary between a word, \w, and > non-word, > \W, character, or the start or end of the string. /\Wfoo\W/ matches > ":foo:", but not "foo", but /\bfoo\b/ matches both. The zero-width > means it consumes nothing; the test is of the character either side. Yes, I was aware of \b support in some languages, but RE support varies across languages, and, knowing this but not being experienced in PERL, I checked at least two online sources for PERL REs and could find no evidence of support for it. If you're a PERL programmer and therefore know that it works, I concede to your superior knowledge. RE support has varied from none to very complete with every language I've programmed, which includes Assembler, Bash, BASIC, C, COBOL, SQL, and Python, but these days I'm more used to HTML and JavaScript, and before that I was doing quite a lot of work in Java, and, despite their similar sounding names and similarities in basic syntax, the latter two are very different in many, perhaps most, other respects, including REs. So REs are regularly one of those areas I find myself having to refer back to manuals and API documentation in particular cases, and at one point in one particular case got so frustrated with the complexity of the REs I was trying to develop that I spent some time creating a JS RE test page to help develop the code. Ironically, the JS RE Test Page has blossomed into being quite a successful page on my site, but the original page that caused it to be written is still 'under development'!-) > > Pretty much the first item in that list was to declare constants at > > the beginning of the program containing all the fixed or semi-fixed > > values that the program needed > > Though that can put them a long way from their use, removing context > from their definition and requiring it to be put back into their > identifier instead. True, but if that is starting to happen, then one of the other 'rules' was to break a monolithic program into blocks - each of which has one particular purpose, which testing has shown it to do well and without rror - and then build the program up by combining such blocks; because the individual components are known to work, the wider program built from them is likely to be more reliable. Regards. _______________________________________________ get_iplayer mailing list [email protected] http://lists.infradead.org/mailman/listinfo/get_iplayer
