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?
Mike
