flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <m...@teotigraphix.com>
Subject Re: Flex SDK code conventions
Date Thu, 05 Jan 2012 20:48:31 GMT

> We've been using a variant subset of these conventions (so much for coding
> conventions) and made some changes that I think are worth being discussed.
> For instance, repeating an accessor name in the block comment is cumbersome
> when refactoring the accessor name as the documentation is not updated.
> Although your IDE might do a code replace as well as a text replace, this
> is not ideal as it will most likely change the text in unwanted places. IMO
> it is better just to have a separator line (the first line of 40 chars)
> above the accessor so you can visually distinguish between blocks of
> accessors without repeating the accessor name.

+1 on this, although I kinda of favored it in say Flex 2, it's very  
depressing if I got out the calculator and figured out how much time I  
spent pasting those and updating them before we had code templates in  
IDEs. :)

Christophe is talking about

// fooBar

public function get fooBar():void

> Other changes are tabs instead of spaces, braces alignment and a few others.

I have been researching this a bit in some other apache projects and I  
have heard on argument against tabs. It's come up with svn commits and  
programs/emails etc that display the commits. They says tabs on a lot  
fo commits make the merge info really hard to read. I'm interested if  
anybody else has heard any other arguments against tabs that don't  
involve opinion.

Braces, ew that is the most hot topic there is. If you switch them, I  
think that would not be wise. My opinion on braces is we have to use  
the grandfathering clause here and accept what is already existent in  
the huge amount of code. Just my thought

> If there is a discussion being set up to discuss and finish the document,
> I'm willing to participate.

> --
> Christophe Herreman

I'd like to get this on the Flex site ASAP as well, anybody else have  
ideas how we can proceed to kill this bug soon?


View raw message