I think it makes code less readable and
Oh lets all agree to disagree on this one. Which side do you butter your bread? On the top or bottom, what??? On the sides!!! ? I can't stand curly braces on the method line, doesn't allow a space from the method signature to fully read and seems cramped to me. But that is my point, you will never get people to agree on spaces, braces and whatever else developers have a habit doing. ... Just because Java / C++ does it, doesn't mean its right. Things always evolve. just kidding, maybe. Peace, Mike On 2/11/07, lepusmars <[EMAIL PROTECTED]> wrote:
I agree, a very interesting read, but one thing I have to disagree with and bothers me a lot that Flex Builder does this when it creates classes. "Close curly braces in its own line at the same position in which the open curly brace is"... nothing bothers me more than a curly brace on it's own line, I think it makes code less readable and contributes to excessive scrolling when editing and reviewing code. Oh and curly braces on case statements is weird, but actually a good convention... that will take some relearning to work into my code. For the most part I like what you have, I'd like to use it as a starting point for my own organization. I think I've come from a different wing of the java development community, since there is a lot that bucks my own traditions. Paul --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, "Ralf Bokelberg" <[EMAIL PROTECTED]> wrote: > > Hi Fabio > > I think it is a good document, beside the whitespace paragraphs. > Distribution of whitespace is always worth a discussion :) > > There is only one thing, that makes me wonder. > If methods should start with a verb, why don't you prefer > handleMouseClick() over mouseClickHandler() ? > > Cheers, > Ralf. > > > On 2/10/07, Fabio Terracini <[EMAIL PROTECTED]> wrote: > > > > Folks, > > > > As my commitment to community I'm releasing, with DClick support, our > > "Adobe Flex Coding Guidelines", a document about Flex (MXML and > > ActionScript) coding conventions that we use on a regular basis. > > > > The objective is clear: provide a common and consistent language to > > help code comprehension between developers. The practices established > > in this document are based on Java conventions, Flex 2 SDK and DClick > > team experience (including myself). > > > > By releasing this document, the idea is to help the community improve > > their Flex code by using coding conventions as well and hear feedback > > from community to continuously improve this document, that by now is a > > community asset. > > > > I'll be happy to have volunteers to form a committee or something to > > evolve this project further. > > > > This way, comments on this document (including the best practices) are > > very welcome! Involve yourself in this flexcoders thread, at the > > flexdev (listaflexdev.org - portuguese list on Flex) or at DClick > > weblog (http://blog.dclick.com.br/2007/02/10/adobe-flex-coding-guidelines/ > > ) > > > > English version: > > > > http://blog.dclick.com.br/wp-content/uploads/adobe-flex-coding-guidelines-v12-english.pdf > > > > Portuguese version: > > > > http://blog.dclick.com.br/wp-content/uploads/adobe-flex-coding-guidelines-v12-portugues.pdf > > > > Thanks, > > Fabio Terracini > > > > > > > > -- > Ralf Bokelberg <[EMAIL PROTECTED]> > Flex & Flash Consultant based in Cologne/Germany > Phone +49 (0) 221 530 15 35 >
-- Teoti Graphix http://www.teotigraphix.com Blog - Flex2Components http://www.flex2components.com You can find more by solving the problem then by 'asking the question'.
