FlashApe

FlashApe » Flex MXML Code Formatting?

Flex MXML Code Formatting?

July 27th, 2008
8:39 pm

Just throwing this question out there to pick the brains of other Flex developers: Do you have any preferences/standards that you follow for your mxml formatting? Care to share? Here are the formats I seem to come across most:

Single line, common attributes grouped together and listed first:

PLAIN TEXT

XML:

<mx:Image id="thumb" x="10" y="20" width="90" height="90" scaleContent="false" source="" />

Single line, with all attributes in alphabetical order:

PLAIN TEXT

XML:

<mx:Image height="90" id="thumb" scaleContent="false" source="" width="90" x="10" y="20" />

Each attribute listed on a new line:

PLAIN TEXT

XML:

<mx:Image
id="thumb"
x="10"
y="20"
width="90"
height="90"
scaleContent="false"
source=""
/>

Personally, I don't have a standard yet. I usually go with tags on a single line, but the attribues are in no particular order at all, except in pairs where it make sense, like x & y always together. I do go with each attribute on a single line for the opening tag of a component or the main Application, though...seems to make more sense to do it there.

flash

20 People had this to say...

Usually I go with the first one.
But when the line gets long I switch to the third solution.
I prefer up/down scroll to left/right.

I usually go with grouped attributes on multiple lines. For example, x and y on a line, width and height on a line, etc. Of course, many attributes are unique and live on a line by themselves. I also try to always put the id attribute first.

I usually have the layout-related properties (x, y, width, height) as attributes and the rest as child elements, but it depends on the situation. I usually aim for short lines, but avoid line breaks within elements.

I usually put attributes such as name, id and stuff like that first and then break the line when the width gets too long so i don't have to scroll left/right. Physical properties(x,y,width,etc...) usually come after non physical attributes.

If you are developing in a team with source version control, it is better to use the third option, to avoid conflicts when several developers are editing the same files.

I try to maintain the 80 char column width using the "show print margin" setting. For both AS & MXML. And as @funkyboy mentioned, follow style 1, and jump to style 3, when i hit the 80 char margin. And when I break lines, I tend to group attributes based on their relevance - like x & y properties in one line, width & height in another etc.

1st one if there are only one or two attributes, but usually the 3rd, but improved as follows (if my html works out)...

I find it far easier to read two columns of name value pairs.

Definitely the third one unless it's a very short or insignificant tag. This way, it's easy to re-arrange the attributes using the alt-up and alt-down keyboard shortcuts. In my world, the id goes at the top, visual attributes next and event listeners at the bottom.

The alphabetical example is a bit much, don't you think?

I agree with Bryan's assessment (which was good to hear from someone else) that thinking of the attributes in groups is helpful.

Putting one attribute per line is a bit much as well, as it doesn't really help you with reading the code (IMO). Just because you don't need to scroll to the right does not mean that scrolling down a lot more is any easier.

I requested that Flex Builder 3 have a custom source formatter that you could set your preferences on how code gets formatted. I hate it when a developer (or FB's design mode) puts the y attribute before the x, or places them in two different places. it drives me a little crazy.

If you are working with a team, it helps if you try to set some best practices. Even if you don't work in a team, setting some personal best practices will help, as other developers will see your code eventually. Asking the question, Rick, helps us all to look at what we do on a daily basis and see if there might be a better way. Thanks.

Leif

(Sorry for calling you Rick, Rich.)

good 3rd way is good

I also will keep x & y, and width & height on the same line, and other related properties. While you have to scroll more, you NEVER have to scroll right.

I use a combo of 1 & 3. I group similar attributes, on multiple lines. x, y, width, height, all on one line, style info on another, events on the next, etc.

Yeah, I used to do the first, but then hated to break up long elements. Then I saw the second one, switched to, and liked having a convention (I don't have to think about what to do when breaking up a line, everything is the same).

Some other details:

- It's also good for source control (as previously mentioned). I group related attributes together (x/y, width/height, borderStyle/borderThickness/cornerRadius, backgroundColor/backgroundAlpha, etc.).

- I put event listeners at the end.

- I put id on the same line as the element name (picked that up from somewhere, I like it).

- I usually put the attributes most significant to the element first, with layout attributes second and style elements last (order of importance).

I usually go for the first, and for tag with tons of attributes, the third one.

Third one makes it readability for big tags to, especially when you are working in a team

[...] Source [...]

The funny thing about MXML is that no matter which way you format it, it always seems to still look ugly.

Hi,
I've found a good starting point here:

http://preview.tinyurl.com/24orv6

I prefer double indenting properties beyond first line not to align them with inner tags:

Regards, Alessandro

Thanks for all the feedback. I think I'm going to go with the 3rd way, with related attributes on a single line and see how that works out.

[...] Flex MXML Code Formatting? I use a combination of 1 and 3. I only use 2 if I have time to kill and that’s never. [...]

I hope someone at Adobe checks out this post and recognizes the need for better custom code formatting support in Flex Builder.

Want your say?

Contact

Email: rich@visible-form.com AIM: flashape

Flex MXML Code Formatting?

20 People had this to say...

Want your say?

Contact

Search this site

Gullible

Categories

Archives