--- In firstname.lastname@example.org
, "Jim Ley" <jim@j...> wrote:
> "Gordon Bowman" <gordon_bowman@h...> wrote in message
> > Any obfuscated code can be unobfuscated, but it's only trivial if
> > the obfuscation process itself was trivial, e.g. garbled via
> > search and replace. Even then, you're guessing at what the
> > variable names are, losing the semantics of it, and making it
> > difficult for the code to be maintable without a lot of work in
> > figuring out what variables and functions are actually for and
> > naming them appropriately.
> Not particularly difficult since the DOM interactions cannot be
> they're the key elements for understanding what the code does.
True, but even with the DOM methods unchanged, we've all written
algorithms that have indepth comments to help us understand the
logic behind it at a later date. When those comments and the
meaningful variable names disappear, it can take time to make sense
of it all, intact DOM methods or no.
> > Obfuscation can get a lot more
> > complicated, of course, with flow-control obfuscation,
> > etc. Basically, obfuscation simply serves as a deterrent, making
> > more trouble than it's worth to try to steal the code instead of
> > legally writing it from scratch.
> I would say obfuscations only value is in rebutting a defence of
> mis-use of your code when someone has stolen it, if there were
> to read the code.
Yes, I forgot that one. But I would say this is "another" value of
obscuation, not the only one.
> The "more trouble to steal than rewrite" I find on the web is
> achieved just by not writing very good script.
> > As well, as I mentioned in a post last summer, obfuscation can
> > improve the run-time performance (as well as making the code size
> > smaller). Back when I was working on Corel's dSVG, we found that
> > obfuscated code outperformed the non-obfuscated
> > code "significantly".
> Yep, I've seen that a stated a lot, it's also undoubtedly true if
> optimise your code as you write it, but I've never seen it true
> which has been written for speed. (The general reason is the
> references which you get as part of the obfuscation process, you
can just do
> that yourself.)
The obfuscation that resulted in improved performance was a simple
search and replace, nothing intelligent about it.
> So whilst you could gain this optimisation you do it at a
> support and QA cost - you're QA'ing different code to what you
> against, line numbers and variable names mentioned in errors are
> to what you develop against.
That's not really any different than the standard practice of
developing a C++ application in DEBUG mode, while giving optimized
RELEASE builds to QA.