is there a way to trace the compiler command for flash builder? I mean, I want to know the parameters and files that is compiling internally when I click "build" on FB.
Basically I moved a project to Flash Builder, and everything works fine but I have some runtime issues, and looks like the compiler is doing something wrong with some files (like using old files instead of using the one im changing, this occur only for a particular file, the rest works fine or I think that works fine). Also is different the way to embed some file, that's another reason to check what's doing internally.
I ran the game with mxmlc before, and probably I can compare what's the difference if I get the command executed by FB.
Also, I want to know how to do it if I need to research something in future.
Thanks for any help,
Regards
Flash Builder only recompiles if there has been a change to the code. So if you are changing an asset (image), for example, you won't recompile unless you also make a change to the project.
There are a few ways around this:
Easiest way is to just go into a file and press the space bar at the end of a line. It will add an extra byte to your file, but not to the project (compiler is "smart" and gets rid of unused files, classes, and characters). Since this is not a common thing, it shouldn't be an issue
Project->Clean.... That will force your workspace to rebuild and, in most cases, will also recompile your project
If #2 is failing, first delete bin-debug or whatever you are using as your debug folder, then run Project->Clean...
It's a tad bit annoying (especially when editing external libraries), but it allows for quicker re-launches of the debugger, which is the ultimate goal of that behavior.
I am very new to Alchemy and not an expert in using swc to store code(Although I am well aware that it worked for me so far). I want to make sure I understand if Alchemy is the right tool for me in this situation.
I want to make a simple script in Alchemy to help make certain 'heavy lifting' in the code lighter and less time consuming and ooze out more performance. The trick is that my colleagues will likely be daunted by the installation process(even though there is a guide). So my question is, if I do take the time to work with Alchemey, can I make my code available to other people that do not use it, for our project?
Hope that makes sense, my instincts (gut feeling) says yes. I simply want to make sure.
Yes, this is exactly what SWCs are for, you can compile your C++ code with FlasCC and expose a simple AS3 API that other people can use by linking your SWC into their project. Download the FlasCC beta and check out the tutorials it comes with that explain this in more detail: http://gaming.adobe.com/technologies/flascc/
Shortly, the answer is yes.
The point is you can't recompile the SWC into an SWF if you don't use alchemy. What you can do, is download at runtime (using Loader.load with ApplicationDomain.currentDomain) the SWF contained into the SWF (SWC is a simple zip, extract it).
Then, you can freely use the class that's inside, using ApplicationDomain.getDefinition("OneOfYourClass).
More about application domain
Since it's at runtime, you won't have to compile Alchemy, thus it should work fine for anyone.
I have a basic problem with knowing which classes to import for a given application, renderer, AS package, mxml component, etc. There seems to be hundreds of classes (both mx and flash) and I'm never sure which one(s) to import... so I just keep adding import statements until the errors go away. Is there a reference somewhere that I don't know about? Or does this just come with experience? Also... does importing a load of classes actually make the file size larger or does Flex only import the classes used nregardless of what I specify? If it only uses what is needed, why wouldn't everyone just do: import mx.*;
I would suggest that if you find yourself bringing in tons of imports, you should ask yourself: Does this class do to much?
It is less of a technical issue, and more of problem of object-oriented design -- maintainability, testability and stability.
I do my best to limit my external dependencies. I try to conform to SOLID principles that tell me that classes should exist for one reason. If a class does too much, it is a "code smell" and an indication that you should split it up.
How much is too much? It is tough to have a specific litmus test or limit... I just ask myself "What does this class do"? If my answer contains an "and" in it, then I consider splitting it up.
I think your problem is a not a real problem if you use any half decent IDE. If you're not using one, you probably should (even if it's not stricly necessary and you can write and compile with notepad and the command line).
If you are using Flex/Flash Builder, it will add the imports automatically (and remove the unneeded ones as well). Also, you can use Ctrl + SPACE to prompt autocomplete, which should add the necessary imports.
Flash Develop also manages this for you (the shortcut was Ctrl + Shift + 1 if I recall correctly, but I haven't used FD for a while).
There are other IDEs out there that I haven't personally used but also have this very basic feature.
If you're using the Flash IDE, well, it really sucks for writting code, so you should probably consider writting your code in some other less brain-dead editor if you plan to do anything more than a couple of lines of code here and there (again, you can write code in the Flash IDE but why not taking advantage of better tools when they're available?).
When you get an error, look at the API Reference for the class, and then either import the whole package or just the class you want. Highlighting the class and hitting F1 should also work (but I never search help this way).
As for file size, see my answer on Is it possible to dynamically create an instance of user-defined Class in Action Script 3?
As Juan pointed out, use FlashDevelop, it is a great (and free) IDE.
If you're using FlashDevelop with the Flex Compiler, you can compile straight from FlashDevelop, and use the refactoring tools they offer to slim down your imports.
Aside from that though, if you're not referencing them, they don't get compiled, so it's not like your compiled swf is any bigger.
I'm working on a tool that will generate the source code for an interface and a couple classes implementing that interface. My output isn't particularly complicated, so it's not going to be hard to make the output conform to our normal code formatting standards.
But this got me thinking: how human-readable does auto-generated code need to be? When should extra effort be expended to make sure the generated code is easily read and understood by a human?
In my case, the classes I'm generating are essentially just containers for some data related to another part of the build with methods to get the data. No one should ever need to look at the code for the classes themselves, they just need to call the various getters the classes provide. So, it's probably not too important if the code is "clean", well formatted and easily read by a human.
However, what happens if you're generating code that has more than a small amount of simple logic in it?
I think it's just as important for generated code to be readable and follow normal coding styles. At some point, someone is either going to need to debug the code or otherwise see what is happening "behind the scenes".
Yes!, absolutely!; I can even throw in a story for you to explain why it is important that a human can easily read the auto generated code...
I once got the opportunity to work on a new project. Now, one of the first things you need to do when you start writing code is to create some sort of connection and data representation to and from the database. But instead of just writing this code by hand, we had someone who had developed his own code generator to automatically build base classes from a database schema. It was really neat, the tedious job of writing all this code was now out of our hands... The only problem was, the generated code was far from readable for a normal human.
Of course we didn't about that, because hey, it just saved us a lot of work.
But after a while things started to go wrong, data was incorrectly read from the user input (or so we thought), corruptions occurred inside the database while we where only reading. Strange.. because reading doesn't change any data (again, so we thought)...
Like any good developer we started to question our own code, but after days of searching.. even rewriting code, we could not find anything... and then it dawned on us, the auto generated code was broken!
So now an even bigger task awaited us, checking auto generated code that no sane person could understand in a reasonable amount of time... I'm talking about non indented, really bad style code with unpronounceable variable and function names... It turned out that it would even be faster to rewrite the code ourselves, instead of trying to figure out how the code actually worked.
Eventually the developer who wrote the code generator remade it later on, so it now produces readable code, in case something went wrong like before.
Here is a link I just found about the topic at hand; I was acctually looking for a link to one of the chapters from the "pragmatic programmer" book to point out why we looked in our code first.
I think that depends on how the generated code will be used. If the code is not meant to be read by humans, i.e. it's regenerated whenever something changes, I don't think it has to be readable. However, if you are using code generation as an intermediate step in "normal" programming, the generated could should have the same readability as the rest of your source code.
In fact, making the generated code "unreadable" can be an advantage, because it will discourage people from "hacking" generated code, and rather implement their changes in the code-generator instead—which is very useful whenever you need to regenerate the code for whatever reason and not lose the changes your colleague did because he thought the generated code was "finished".
Yes it does.
Firstly, you might need to debug it -- you will be making it easy on yourself.
Secondly it should adhere to any coding conventions you use in your shop because someday the code might need to be changed by hand and thus become human code. This scenario typically ensues when your code generation tool does not cover one specific thing you need and it is not deemed worthwhile modifying the tool just for that purpose.
Look up active code generation vs. passive code generation. With respect to passive code generation, absolutely yes, always. With regards to active code generation, when the code achieves the goal of being transparent, which is acting exactly like a documented API, then no.
I would say that it is imperative that the code is human readable, unless your code-gen tool has an excellent debugger you (or unfortunate co-worker) will probably by the one waist deep in the code trying to track that oh so elusive bug in the system. My own excursion into 'code from UML' left a bitter tast in my mouth as I could not get to grips with the supposedly 'fancy' debugging process.
The whole point of generated code is to do something "complex" that is easier defined in some higher level language. Due to it being generated, the actual maintenance of this generated code should be within the subroutine that generates the code, not the generated code.
Therefor, human readability should have a lower priority; things like runtime speed or functionality are far more important. This is particularly the case when you look at tools like bison and flex, which use the generated code to pre-generate speedy lookup tables to do pattern matching, which would simply be insane to manually maintain.
You will kill yourself if you have to debug your own generated code. Don't start thinking you won't. Keep in mind that when you trust your code to generate code then you've already introduced two errors into the system - You've inserted yourself twice.
There is absolutely NO reason NOT to make it human parseable, so why in the world would you want to do so?
-Adam
One more aspect of the problem which was not mentioned is that the generated code should also be "version control-friendly" (as far as it is feasible).
I found it useful many times to double-check diffs in generated code vs the source code.
That way you could even occasionally find bugs in tools which generate code.
It's quite possible that somebody in the future will want to go through and see what your code does. So making it somewhat understandable is a good thing.
You also might want to include at the top of each generated file a comment saying how and why this file was generated and what it's purpose is.
Generally, if you're generating code that needs to be human-modified later, it needs to be as human-readable as possible. However, even if it's code that will be generated and never touched again, it still needs to be readable enough that you (as the developer writing the code generator) can debug the generator - if your generator spits out bad code, it may be hard to track down if it's difficult to understand.
I would think it's worth it to take the extra time to make it human readable just to make it easier to debug.
Generated code should be readable, (format etc can usually be handled by a half decent IDE). At some stage in the codes lifetime it is going to be viewed by someone and they will want to make sense of it.
I think for data containers or objects with very straightforward workings, human readability is not very important.
However, as soon as a developer may have to read the code to understand how something happens, it needs to be readable. What if the logic has a bug? How will anybody ever discover it if no one is able to read and understand the code? I would go so far as generating comments for the more complicated logic sections, to express the intent, so it's easier to determine if there really is a bug.
Logic should always be readable. If someone else is going to read the code, try to put yourself in their place and see if you would fully understand the code in high (and low?) level without reading that particular piece of code.
I wouldn't spend too much time with code that never would be read, but if it's not too much time i would go through the generated code. If not, at least make comment to cover the loss of readability.
If this code is likely to be debugged, then you should seriously consider to generate it in a human readable format.
There are different types of generated code, but the most simple types would be:
Generated code that is not meant to be seen by the developer. e.g., xml-ish code that defines layouts (think .frm files, or the horrible files generated by SSIS)
Generated code that is meant to be a basis for a class that will be later customized by your developer, e.g., code is generated to reduce typing tedium
If you're making the latter, you definitely want your code to be human readable.
Classes and interfaces, no matter how "off limits" to developers you think they should be, would almost certainly fall under generated code type number 2. They will be hit by the debugger at one point of another -- applying code formatting is the least you can do the ease that debugging process when the compiler hits those generated classes
Like virtually everybody else here, I say make it readable. It costs nothing extra in your generation process and you (or your successor) will appreciate it when they go digging.
For a real world example - look at anything Visual Studio generates. Well formatted, with comments and everything.
Generated code is code, and there's no reason any code shouldn't be readable and nicely formatted. This is cheap especially in generated code: you don't need to apply formatting yourself, the generator does it for you everytime! :)
As a secondary option in case you're really that lazy, how about piping the code through a beautifier utility of your choice before writing it to disk to ensure at least some level of consistency. Nevertheless, almost all good programmers I know format their code rather pedantically and there's a good reason for it: there's no write-only code.
Absolutely yes for tons of good reasons already said above. And one more is that if your code need to be checked by an assesor (for safety and dependability issues), it is pretty better if the code is human redeable. If not, the assessor will refuse to assess it and your project will be refected by authorities. The only solution is then to assess... the code generator (that's usually much more difficult ;))
It depends on whether the code will only be read by a compiler or also by a human. In addition, it matters whether the code is supposed to be super-fast or whether readability is important. When in doubt, put in the extra effort to generate readable code.
I think the answer is: it depends.
*It depends upon whether you need to configure and store the generated code as an artefact. For example, people very rarely keep or configure the object code output from a c-compiler, because they know they can reproduce it from the source every time. I think there may be a similar analogy here.
*It depends upon whether you need to certify the code to some standard, e.g. Misra-C or DO178.
*It depends upon whether the source will be generated via your tool every time the code is compiled, or if it will you be stored for inclusion in a build at a later time.
Personally, if all you want to do is build the code, compile it into an executable and then throw the intermediate code away, then I can't see any point in making it too pretty.