💩  The Good, the Bad, and the Ugly

One negative thing that the tools in the Unicode Tool Chest is that there exists far, far too much of the absolutely worst possible kind of code reuse imaginable: good ol’ murine snarf’ɴ’barf, so to speak.

I recognize this and abhor it, and I profoundly apologize. But please understand that these grew organically over a period of a few months, and so it wasn’t at all clear just what should be factored out, what the ᴀᴘɪ needed to be, or how it all fit together as the whole that it has increasingly become. Too much was under constant development to try to do that a priori before having written it. That’s because premature optimization, while perhaps not quite up to the standard of Rᴀᴅɪx Mᴀʟᴏʀᴠᴍ Cᴠᴘɪᴅɪᴛᴀs Esᴛ 😈, is definitely one of my idea of the Seven Deadly Sins of Programming, and so I beg of you if not your forgivenness, at least then your forebearance, in this unintended wickedness. It will get fixed.

Too much framework and too little code is just pointless over‐engineering and needless conplication. I despise those things, but learning to discern what the right time and place for what level of abstraction is, isn’t something that always comes immediately. Sometimes you have to build working prototypes first, then look ack at them to figure out how to refactor for the good of all.

In short, there’s a queasy measure of duplication across programs that should and almost must be factored out and placed into a set of common modules. I am painfully aware of that, and very much hope to someday find the time to do so.

📖 Learning by Example

Meanwhile, take a look at some of that code. There really is a lot to learn from it — mostly, I hope, good things to learn, not bad things. You may see some things that surprise you, stuff that gives the infernal Perl::Critic the fatal heart‐attack it so desperately deserves.

And you will also see certain things that are not there. There are elements that someone or other may have told you that you should include in order for your code to pass muster. Sometimes it’s unjustly beating someone over the head with Damian’s Perl Best Practices, and sometimes the supercilious bashing comes from other sources. But it is all bogus and unnecessary, and I believe that in the balance it has now done more harm than good. Tʜᴇʀᴇ’s ᴍᴏʀᴇ ᴛʜᴀɴ ᴏɴᴇ ᴡᴀʏ ᴛᴏ ᴅᴏ ɪᴛ, and don’t you dare forget it.

¡ʞʍɐ uᴉ əpoɔ ɹnoλ əʇᴉɹʍəɹ noλ əʞɐɯ puɐ uʍop noλ ʞɔɐɹʇ ⁎llᴉʍ⁎ I əƨlə ɹO

Looking over my recent code, I guarantee that you will learn a whole lot about my notions of good coding style, including but hardly limited to the proper use and placement of parentheses, much better than I could ever here put into short, simple words. Osmosis works a lot better.

Sure, I certainly have my rules and ideas, but I am not sure I’m ready to explain them in English. And I especially never want to imply that you must code your Perl as I do mine.

I just want you to see what I do, understand why due to its consistency it works as a coherent, reliable, safe, and predictable style (perltidy and Perl::Critic be damned!), and only then consider making your own decisions about what you do or do not fancy. I don’t expect everyone to agree with everything. In fact, I would be disappointed if it turned out that way.

The single overarching point about my code is that it has a distinctive and readily identifiable style running throughout, which has therefore extreme inherent virtue, no matter whether you agree with certain of its particulars or not.

☞ What’s the point?

The point is all about internal self‐consistency. Period.

The point is not following other people’s rules, howsoever well‐meaning those rules might have originally been. This point is almost always lost these days, and it is a crying shame.

My Perl code itself should be crystal clear. If it isn’t, then I’m not doing something right. Anything in there that isn’t aeons old (of which there are only two) should also be wholly neoteric, completely self‐consistent, and in places even a pleasure to read.