note
jonadab
<p>Some additional tips...</p><ul>
<li>First, think of something interesting to do.
Second, think of an unobvious way to accomplish
it. <em>Then</em> start writing the code. With
an obfuscated algorithm from the get-go, and code
that does something interesting, your obfu will
be sure to please.</li>
<li>Avoid using <code>if (condition) { foo; }
else { bar; }</code>
when you can instead use the trinary operator:
<code>(condition)?foo:bar;</code>. This is
especially important when you have nested
conditionals.</li>
<li>Try to model parts of your code around paradigms
that a lot of people aren't familiar or comfortable
with, such as functional or logical programming.
Combine these with often-poorly-understood data
structures if possible. For instance, having map
generate a hashref of closures each iteration is
sure to confuse at least some of the people
reading your code.</li>
<li>Include POD that is simultaneously cryptic and
actively misleading.</li>
<li>Play strange games with context and precedence.</li>
<li>Abuse symbolic references.</li>
<li>Include at least one red herring, but make sure
that it is just as obfuscated and hard to follow
as the rest of the code, so that it will not be
immediately written off as a red herring.</li>
<li>While writing your code, go ahead and use
obfuscatory techniques, but keep some line
breaks and comments in so you can keep track
of what you're doing; once you get it working
just the way you want and nicely obfuscated,
then remove the comments, golf it down a little,
and alter the whitespace to reform the code into
the shape you want; test after every couple of
changes to make sure it still does what
you want.</li>
<li>Don't break up into subroutines at the natural
places; leave things inline that in real code would
be better broken out as subroutines, and instead
break things out as subroutines that would be
better off inline in real code. Make sure your
subroutines do things with the caller's variables,
if possible.</li>
<li>Try to use hashes and arrays with the same
single-character names as the scalars you are
using, especially any punctuation-named special
variables you are abusing.</li>
<li>When using regular expressions, don't use regular
/slashes/ as delimiters; find more interesting
characters for that, preferably ones that are
also used for other things both within the
regexen (where they will have to be escaped)
and near them in the code.</li>
<li>Abuse the /e modifier with regex substitutions.</li>
<li>Nested string eval can be fun; combine it with
$_ and substitutions to create self-modifying
code.</li>
<li>Use things for multiple unrelated purposes.
For instance, if you have an array or hash that
you happen to know contains some elements, you
can grab it in scalar context any time you need
a true value. Similarly, any variable that
you know contains a non-numeric string can be
used as zero in numeric context. Apply this
principle as often as possible, in as many
different ways as possible.</li>
<li>Converting foreach and even while loops into
<code>map</code> will often shave off several
characters, with the added benefit of allowing
you to assign the result to an array (or hash!)
which you can subsequently use as a red herring,
a true value in boolean context, or even as a
number.</li>
<li>Golf, but don't overgolf. Frequently the absolute
shortest way to say something is not the most
confusing.</li>
</li>
<!-- Node text goes above. Div tags should contain sig only -->
<div class="pmsig"><div class="pmsig-230012">
<hr />
"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."
— Pratico & Van Pelt, BBHG, p68
</div></div>
20312
20312