Home >
Conditional compilation allows developers to tell the compiler not to include certain parts of their code unless a set of conditions are met. Apparently Adobe added this feature to Flex 3, though I hadn't heard anything about this until this morning when Jim Cheng sent me the LiveDoc link.
You might be wondering, why would I ever use something like that? Well, I'm glad you asked. Conditional compiling is incredibly useful in a few different situations, and chances are you're already solving some of the problems conditional compiling address the hard way. Ever flagged a section of your code with a big static variable to turn it on and off? Ever written a debug method you commented out later, or simply removed all the references to? If you're from the old C++ world, ever used #ifdef? If the answer to any of these questions is "yes" or "maybe" or even "no, but as a curious developer I'd sure like to know more!", then read on.
First, conditional compilation is useful in complex debugging. Sometimes you want to run a bit of debug code that tells you something a simple debug session won't. Rather than commenting this code out or flagging it with some sort of compiler variable, you can now code debug sections in to your heart's content. Just tell your compiler to ignore anything in the "debug" namespace and you'll be fine.
Second, it's great for building simultaneous AIR builds with your flex apps. Let's say you've got a class that's useful for both an AIR app and a Flex app, but the AIR app needs a little extra code, or includes a feature your Flex app can't support. Rather than reproducing all of the useful code or extending the class and overriding the methods in question, you can flag certain sections to only be compiled for AIR and ignored by Flex.
Third, it's useful for monkey-patching. Monkey-patching is a messy process that I don't recommend, but sometimes it's the best solution to a problem. In these situations it'd be nice to easily toggle on and off our monkey patched classes to see if they're working, how they're affecting the application, and hopefully remove them when Adobe implements the bug fixes we're undoubtedly patching around. :)
So check it out. If nothing else, by removing the need for commented-out debug methods or big static variable flags, conditional compilation will help you write cleaner code and earn you the respect and admiration of your co-workers.
Tag Cloud
Podcasts & Screencasts
@InsideRIA on Twitter
Follow InsideRIA on Twitter
Facebook Application Development
Oh no, the nightmare begins again ...
I spent hours in my first job having to deal with #ifdefs to cope with compiling ANSI C code for MDL applications (Bentley's MicroStation) for different platforms (Windows, and AS400 mainly). It was one of the main "features" of C that I was more than happy to leave behind when I stared using Java.
I'm afraid I just can't see the value in it. I think it is also especially dangerous for QA reasons. For example, as you go through your project you are no doubt releasing early and often in to your QA team, they go about happily finding no bugs in your software. Woohoo! But then it's production time and you decide to recompile your project using a different config, i.e. in order to remove those pesky debug statements (reducing your binary size and uncessary execution cycles) but when you hand over your production version to your QA team - BANG! A crap load of bugs because they are now testing *different code*.
I'm sure you've had that scenario where "it works when I have a debug statement in", well this is just asking for that to happen.
As for partitioning code for AIR or Flex, if you architect your code properly and make proper use of libraries and modules why would you need this mechanism?
I think I would prefer it if it had remained a largely unknown feature - I was happier in ignorance anyway.
Well you certainly don't have to use it. Why are you releasing debug builds to your QA team anyway? Compile in release mode for everyone except the development team and you'll catch those bugs early.
Honestly, this sort of conditional compiling addresses the exact concerns you're voicing. Rather than including a bunch of debug methods that we strip out later or remembering which flags to change for release mode, you just change a single compiler setting and build the release mode for QA.
Good developers are going to and should be putting non-release code into their apps during testing. That stuff needs to be stripped out for size and performance reasons. This is the cleanest and fastest way to keep it out of your release I've ever seen.
Very interesting. I've been trying to sort out a good way to handle AIR and Flex in a single project, I just wish there were more/better examples.
It's a good addition to the compiler. Pity it isn't particularly supported in Flex Builder unless you use something like ANT to manage the build.
here's an example of how to use Flex and AIR in a single project. http://tech.groups.yahoo.com/group/flexcoders/message/91498