Home >
I am thrilled that there is some built-in code formatting in Flash Builder (the next, renamed version of Flex Builder) even if it is only code indenting. Especially because some of my coworkers and I disagree on correct indentation, I find it incredibly useful to be able to hit apple+a, apple+i (that's ctrl+a, ctrl+i, for you non-mac users) and instantly have all of my code indented uniformly. You can also use the formatter on a line-by-line basis, if you like.
I did run into some interesting idiosyncrasies with the formatter, though. A little use clearly shows that it bases indentation by moving top-down through your code -- which seems like a fairly standard and practical solution. However, this can lead to some hiccups in certain situations.
First of all, if you're working line-by-line then you'll need to make sure your preceding lines are indented correctly. If you throw an extra tab before an open curly brace, then all the lines below it will respect that extra tab. Now, if you auto-indent the line with the extra tab then the formatter will remove that extra tab and everything below it will be fine. It only matters if you go line-by-line beneath incorrect indentation. To me this isn't really an issue with the formatter, its just a possible point of entry for odd behavior. Its also why I typically don't ask the formatter to indent line-by-line.
Something far less obvious is that the formatter doesn't rely on tabs or curly braces alone for indentation. It also relies on semi-colons. Its not really a big deal, except that the AS compiler doesn't enforce semi-colon use. For example, the other day I was working on a class and my auto-indentation was off because there was a line like this above my code:
if(x == 0)
x++;
else
x--
In this case the formatter treats the following line as though it is nested deeper within the else block:
if(x == 0)
x++;
else
x--
y = 3;
y++;
I don't completely understand the result here -- I'd think that at least you'd see y=3; at the same indentation level as x--. Things get even stranger if we add curly braces to the if/else:
if(x == 0){
x++;
} else {
x--
}
y = 3;
y++;
Now, all of the code after y = 3; is indented as though its still within the if/else. But all of this goes away by adding in the semi-colon where it should have been all along:
if(x == 0)
x++;
else
x--;
y = 3;
y++;
I'm not sure what the algorithm behind the formatter is, but it clearly works best when everyone includes semi-colons at the end of lines that ought to have them. Since including these semi-colons is generally accepted as at least best practice, if not a requirement, this isn't a hugely irritating bug. In fact, I kind of like the fact that it will make it painfully obvious to me if there is a semi-colon missing. But, it can be really confusing the first time you run into it, especially because the behavior is so erratic.
Strange edge-cases aside, I think that Adobe is moving the right direction by adding more formatting features in their AS IDE. Code formatting is a task that is typically tedious and follows a strict set of rules, so its a perfect target for automation. In fact, there are several full featured 3rd party plugins for Eclipse (Flex/Flash Builder is built on Ecilpse) that will format your AS code for you. However, I prefer having built in features for this sort of operation rather than relying on 3rd party packages. Its just simpler. The auto-indentation is a great feature and I hope that you'll come to enjoy it as much as I do, and that Adobe will add more and more formatting features to the builder.
Tag Cloud
Podcasts & Screencasts
@InsideRIA on Twitter
Follow InsideRIA on Twitter
Facebook Application Development
Overall it's nice, but I'd replace the words "thrilled" with "finally" in you post .
It's 2009 and introducing an identation to a code editor of version 4.0 is yet another evidence that there is a lot of room for improvements in the Flash Builder team.
FlexFormatter at http://sourceforge.net/projects/flexformatter/ is a much more complete and customizable option. It has settings for most of the issues anyone cares about related to formatting flex code, and if you have some particular issue that isn't covered, the developer is very receptive to requests for new features. It allows you to export and import settings so you can get your whole team to use the same formatting.
It works with FB3 and FB4.
What Jerry said. +1 vote for the FlexFormatter. Works fine for me in the Flash Builder 4 beta.
And I join the club about FlexFormatter. I can't live without now. Seriously.
Same here; now I'm only missing code templates, it's a pain without them
Hi Greg, glad you like the new feature. The indenter in the "Gumbo" public beta was mid-development, so it was missing a handful of features, including optional semicolon support. We put it in the beta anyway because it's useful as-is, and to get as much customer feedback as we could.
We've since added optional semicolon support (your examples indent propertly in my local dev build), some prefs, and wired up the indenting code to a number of editing workflows, like positioning the cursor when you press enter. This will all show up in the next beta.
I agree that formatting tools and preferences are essential in an IDE, and I intend to keep driving this forward at Adobe.
(if it's not obvious, I'm on the Flash Builder team.)
Scott,
FlexFormatter is BSD licensed. Its way ahead of where FlashBuilder is now and probably way ahead of where it will be when released. Why don't you just incorporate it into FlashBuilder. Why reinvent the wheel.
There are plenty of features that are not available anywhere else, where Adobe's developers could be better deployed.
Jerry - we've discussed that too, and exchanged a few emails with Ernest, who wrote FlexFormatter. The idea is definitely still in play here, but after hearing this suggestion a lot, I feel like it's worth clarifying our thinking a bit.
While it's easy to say "hey, the XYZ project is pretty far along, why not drop it in", it's not that simple. Any formatting code that FB will use is a pretty deep, strategic decision -- it'll end up wired up to lots of different pieces of Builder, wherever we generate code, etc. So we need to feel really good about whatever it is we write or use; it needs interfaces and internals that are compatible with ours; and so on. For instance, FlexFormatter has its own hand-rolled parser; the built-in indenter uses the same internal parser that Builder uses for everything else (language intelligence, syntax highlighting, etc), which means that parser is very fast and well-tested. Another example -- the indenting code was designed to work in a way that makes it effective at positioning the cursor on new lines regardless of the code that precedes the insertion point.
These are just examples, and I'm not saying that FlexFormatter integration is off the table. What I'm saying is that given the goals of deep integration throughout the tool, robustness, awareness of crazy language constructs, and performance, it's a much more nuanced decision than it might seem. Adapting somebody else's code may be harder, or have lower quality results, than rolling our own based on all the plumbing that's already in Builder.
FDT does also an awesome job in code formatting and supporting templates.
http://fdt.powerflasher.com