You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2012/02/26 22:49:34 UTC
Code formatting for patch submissions
Hi,
This has been discussed on the list before but I don't think a consensus was reached. Flex formatter was mentioned as a possible tool but as It's a Eclipse plugin not everyone would have access to it.
In general the code patches should be in the same same style as the surrounding code, but that does vary a bit from place to place.
Flex formatter does have sample output so I've placed this up in my whiteboard area for a) anyone to use and b) anyone to suggest changes to the formatting style.
http://svn.apache.org/viewvc/incubator/flex/whiteboard/jmclean/formatting/
One thing I'd argue changing is code like this:
if (some condition)
a = 1;
else
b = 2;
While it's compact the missing braces can (and often do) cause bugs when the code is modified.
Thanks,
Justin
Re: Code formatting for patch submissions
Posted by Igor Costa <ig...@gmail.com>.
This has been discussed in mailing list before.
I guess this is more related to personal style of coding than overall style.
To myself, the current way of Adobe code styles fits on our needs, we need
to focus on concrete changes, not substantial ones.
Writing a guide to help new contributors is much better than change hole
code way of style.
Like theses does here
http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions and
here
http://www.dclick.com.br/2007/02/13/adobe_flex_coding_guidelines_english/
Regards
----------------------------
Igor Costa
On Mon, Feb 27, 2012 at 8:34 AM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> I suggest we take the pragmatic path in that we take how the current code
> is formatted. Constancy make it easier to work on the code. I'm sure on
> occasion there will be valid reason for breaking those rules and over time
> we may move to a new set of rules.
>
> Thanks,
> Justin
Re: Code formatting for patch submissions
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I suggest we take the pragmatic path in that we take how the current code is formatted. Constancy make it easier to work on the code. I'm sure on occasion there will be valid reason for breaking those rules and over time we may move to a new set of rules.
Thanks,
Justin
Re: Code formatting for patch submissions
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 27/02/2012 16:57, Alex Harui wrote:
> We already had a long discussion on this in the early days of the mailing
> list.
I think there was no consensus - was there?
yours
Martin.
Re: Code formatting for patch submissions
Posted by Alex Harui <ah...@adobe.com>.
On 2/26/12 8:37 PM, "David Francis Buhler" <da...@gmail.com> wrote:
> I believe we just need to standardize on a a set of styles, even if it
> isn't to everyone's liking. Consistency is important for reasons we're all
> aware of, but the standardized formatting is even more important when you
> have very different people working together.
>
> I say we start a new thread and come to an agreement on the formatting
> styles, or perhaps nominate someone to come up with a format we agree to
> adopt.
>
We already had a long discussion on this in the early days of the mailing
list.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Code formatting for patch submissions
Posted by David Francis Buhler <da...@gmail.com>.
I believe we just need to standardize on a a set of styles, even if it
isn't to everyone's liking. Consistency is important for reasons we're all
aware of, but the standardized formatting is even more important when you
have very different people working together.
I say we start a new thread and come to an agreement on the formatting
styles, or perhaps nominate someone to come up with a format we agree to
adopt.
On Sun, Feb 26, 2012 at 11:03 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> > Are we also going to bring up the debate about cuddling v. not
> > cuddling?
> You just did :-)
>
> I assume you mean this:
>
> if (condition) {
> doSomething();
> } else {
> doSomethingElse();
> }
>
> vs
>
> if (condition)
> {
> doSomething();
> }
> else
> {
> doSomethingElse();
> }
>
> Currently the SDK code doesn't cuddle brackets statements so that would be
> the way to go for now.
>
> Thanks,
> Justin
>
> PS It's not my preferred style
Re: Code formatting for patch submissions
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Are we also going to bring up the debate about cuddling v. not
> cuddling?
You just did :-)
I assume you mean this:
if (condition) {
doSomething();
} else {
doSomethingElse();
}
vs
if (condition)
{
doSomething();
}
else
{
doSomethingElse();
}
Currently the SDK code doesn't cuddle brackets statements so that would be the way to go for now.
Thanks,
Justin
PS It's not my preferred style
Re: Code formatting for patch submissions
Posted by JP Bader <jp...@zavteq.com>.
Are we also going to bring up the debate about cuddling v. not
cuddling? 4 spaces v. tab is a good question, but what are the
conventional recommendations regarding cuddling?
JP
On Sun, Feb 26, 2012 at 4:50 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> Which flex formatter properties file did you use to format the code example
>> you made? I sent one in a previous thread, did you use that one or an Adobe
>> one?
>
> Just pushed the button in the preferences marked "Set to Adobe standards". I believe it has a couple of differences to what the "standards" are now but it's a good start.
>
> Thanks,
> Justin
--
JP Bader
Principal
Zavteq, Inc.
@lordB8r | jp@zavteq.com
608.692.2468
Re: Code formatting for patch submissions
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I would, however, be happy if the curly brackets following package
> declaration were allowed to not to create an additional indent
This is done (mostly) in the SDK so can be considered the right way of layout (in my opinion).
Justin
Re: Code formatting for patch submissions
Posted by Alex Harui <ah...@adobe.com>.
On 2/27/12 1:46 PM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
> I'm not arguing the 100 characters limitation, it's only that I will
> probably, instinctively wrap lines before they are that long.
IMHO, you are welcome to wrap lines at any point that aids legibility. 80
is a good number, so is 100 in some cases. And it should be a guide, not a
rule, because you should not have to figure out how to wrap a 128 character
GUID or something like that just because.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Code formatting for patch submissions
Posted by Left Right <ol...@gmail.com>.
A bore in me says: 80 characters limitation isn't related to CRT
technology, it comes from terminals, which inherited this limitation from
analogue devices - typewriters. In the olden days, if you submitted the
manuscript to print, the A4 contained exactly 72 characters in a line typed
on typewriter. It could be even an ISO standard or something. This,
including the width of the margins would make up for 80 characters.
Nowadays some find this limitation out of date, however, it is rooted in a
research into Roman-German family of languages and the optimal number of
characters of an optimal size the human would be likely to digest. This has
been altered many times, and the civilization plagued by computer-generated
texts has lost the battle between the ugly and beautiful :) And, if you are
on a Mac, then the line 100 characters long of the same font, same size
looks _entirely_ different than it looks on PC. Now add to that that some
people use different fonts to render the code, and some particularly
anathemas use variable-width fonts to render the code (Bjorne Straustrup
for instance)!
There are still things that are limiting the code width to 80 characters:
1. Book publishing. If you want your code to retain it's original view in
the book, trust me, 80 characters, and not a single one more!
2. Sending code via e-mail. E-mail systems were invented in between Fidonet
become extinct and just couple million years before the dinosaurs become
extinct. They still wrap text at precisely 80 characters, so if you want to
send your code intact, 80 characters and don't you dare to add more.
3. Mergetools and people that use them. Them people who use them like to
see 3 screenfulls of code at one time [theirs] [merged] [mine]. Having to
scroll the screens yields a lot of yielding at those unaware of 80
characters per line limitation.
I'm not arguing the 100 characters limitation, it's only that I will
probably, instinctively wrap lines before they are that long.
I would, however, be happy if the curly brackets following package
declaration were allowed to not to create an additional indent, because it
creates 12 spaces before you started to write _any_ code at all (which, for
example, according to Linux code guidelines is already too late for you to
write any code). :)
I saw that this was randomly done in some files in the SDK. I'd be in favor
that would be made into a rule.
Best.
wvxvw
Re: Code formatting for patch submissions
Posted by Igor Costa <ig...@gmail.com>.
And I missed to wrote.
What are the others contributors think on overall changes in conventions?
Regards
Igor
On Mon, Feb 27, 2012 at 5:58 PM, Igor Costa <ig...@gmail.com> wrote:
> Gordon
>
> The 2 and 3 item I agree with you to remove those asterisks from comments.
>
> 100 is in my point of view is enough due to we don't only have widescreen
> monitors but tablets, that's loop back to CRT. Why? I do view doc
> specification on my iPad using as my second monitor during training and
> fits pretty well on my view.
>
> Again the code guide currently on FB is much more than I can get. And code
> style guide fits pretty much what we need on Apache Flex project.
>
>
> Most devs and contributors of already open program by Adobe are used to
> this code style, changing it is like what happened in flex 3 to flex 4
> migration docs and specs. And the current style fits on the side of each
> Java dev, which is 85% compatible style code guide where you can check out
> here http://www.oracle.com/technetwork/java/codeconv-138413.html
>
>
>
> Regards
> Igor Costa
>
> On Mon, Feb 27, 2012 at 5:31 PM, Omar Gonzalez <om...@gmail.com>wrote:
>
>> On Mon, Feb 27, 2012 at 12:03 PM, Carol Frampton <cf...@adobe.com>
>> wrote:
>>
>> >
>> >
>> > On 2/27/12 1 :55PM, "Gordon Smith" <go...@adobe.com> wrote:
>> >
>> > >I wrote Adobe's coding guidelines for ActionScript and I noticed a few
>> > >ways in which this formatting doesn't match what the framework's
>> current
>> > >conventions:
>> > >
>> > >1. We wrap lines at 80 characters.
>> >
>> > Gordon we changed the wrap to 100 characters last year when we updated
>> the
>> > spec. If you use FlashBuilder you can configure the Text Editor to show
>> > the print margin at 100 which is a handy reference.
>> >
>> > Carol
>>
>>
>> I think 100 sounds more reasonable. 80 is old school CRT days, I'm pretty
>> sure most people are on widescreen monitors now. Don't want to get carried
>> away either and allow never ending lines, 100 seems reasonable.
>>
>> --
>> Omar Gonzalez
>> s9tpepper@apache.org
>> Apache Flex PPMC Member
>>
>
>
Re: Code formatting for patch submissions
Posted by Igor Costa <ig...@gmail.com>.
Gordon
The 2 and 3 item I agree with you to remove those asterisks from comments.
100 is in my point of view is enough due to we don't only have widescreen
monitors but tablets, that's loop back to CRT. Why? I do view doc
specification on my iPad using as my second monitor during training and
fits pretty well on my view.
Again the code guide currently on FB is much more than I can get. And code
style guide fits pretty much what we need on Apache Flex project.
Most devs and contributors of already open program by Adobe are used to
this code style, changing it is like what happened in flex 3 to flex 4
migration docs and specs. And the current style fits on the side of each
Java dev, which is 85% compatible style code guide where you can check out
here http://www.oracle.com/technetwork/java/codeconv-138413.html
Regards
Igor Costa
On Mon, Feb 27, 2012 at 5:31 PM, Omar Gonzalez <om...@gmail.com>wrote:
> On Mon, Feb 27, 2012 at 12:03 PM, Carol Frampton <cf...@adobe.com>
> wrote:
>
> >
> >
> > On 2/27/12 1 :55PM, "Gordon Smith" <go...@adobe.com> wrote:
> >
> > >I wrote Adobe's coding guidelines for ActionScript and I noticed a few
> > >ways in which this formatting doesn't match what the framework's current
> > >conventions:
> > >
> > >1. We wrap lines at 80 characters.
> >
> > Gordon we changed the wrap to 100 characters last year when we updated
> the
> > spec. If you use FlashBuilder you can configure the Text Editor to show
> > the print margin at 100 which is a handy reference.
> >
> > Carol
>
>
> I think 100 sounds more reasonable. 80 is old school CRT days, I'm pretty
> sure most people are on widescreen monitors now. Don't want to get carried
> away either and allow never ending lines, 100 seems reasonable.
>
> --
> Omar Gonzalez
> s9tpepper@apache.org
> Apache Flex PPMC Member
>
Re: Code formatting for patch submissions
Posted by Omar Gonzalez <om...@gmail.com>.
On Mon, Feb 27, 2012 at 12:03 PM, Carol Frampton <cf...@adobe.com> wrote:
>
>
> On 2/27/12 1 :55PM, "Gordon Smith" <go...@adobe.com> wrote:
>
> >I wrote Adobe's coding guidelines for ActionScript and I noticed a few
> >ways in which this formatting doesn't match what the framework's current
> >conventions:
> >
> >1. We wrap lines at 80 characters.
>
> Gordon we changed the wrap to 100 characters last year when we updated the
> spec. If you use FlashBuilder you can configure the Text Editor to show
> the print margin at 100 which is a handy reference.
>
> Carol
I think 100 sounds more reasonable. 80 is old school CRT days, I'm pretty
sure most people are on widescreen monitors now. Don't want to get carried
away either and allow never ending lines, 100 seems reasonable.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: Code formatting for patch submissions
Posted by Carol Frampton <cf...@adobe.com>.
On 2/27/12 1 :55PM, "Gordon Smith" <go...@adobe.com> wrote:
>I wrote Adobe's coding guidelines for ActionScript and I noticed a few
>ways in which this formatting doesn't match what the framework's current
>conventions:
>
>1. We wrap lines at 80 characters.
Gordon we changed the wrap to 100 characters last year when we updated the
spec. If you use FlashBuilder you can configure the Text Editor to show
the print margin at 100 which is a handy reference.
Carol
>
>2. We make the first line of a multiline comment be /* or /** with no
>text.
>
>3. We put an asterisk on every line of a multiline comment.
>
>4. We line up the asterisks in a multiline comment.
>
>5. We use two spaces after the asterisks so that the text starts at the
>same indent position as code.
>
>- Gordon Smith, Adobe
>
>
>-----Original Message-----
>From: Justin Mclean [mailto:justin@classsoftware.com]
>Sent: Sunday, February 26, 2012 2:50 PM
>To: flex-dev@incubator.apache.org
>Subject: Re: Code formatting for patch submissions
>
>Hi,
>
>> Which flex formatter properties file did you use to format the code
>> example you made? I sent one in a previous thread, did you use that
>> one or an Adobe one?
>
>Just pushed the button in the preferences marked "Set to Adobe
>standards". I believe it has a couple of differences to what the
>"standards" are now but it's a good start.
>
>Thanks,
>Justin
Re: Code formatting for patch submissions
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 28/02/2012 04:16, Ariel Jakobovits wrote:
>> 1. We wrap lines at 80 characters.
> Ugh, I hate that. Can we change that to more like 140 chars, or no wrapping?
You should have a regulated wrapping because else you have 3000 char
line monsters.
I read somewhere between 12 and 14 words is a good line length, in terms
of readability, in documentation:
14 * 5 chars (average word length english) + 13 whitespaces + 4
characters prefix = 87
I am fine with 80 chars for documentation. I have made good experiences
with enforcing that.
yours
Re: Code formatting for patch submissions
Posted by Ariel Jakobovits <ar...@yahoo.com>.
> 1. We wrap lines at 80 characters.
Ugh, I hate that. Can we change that to more like 140 chars, or no wrapping?
Ariel Jakobovits
Email: arieljake@yahoo.com
Phone: 650-690-2213
Fax: 650-641-0031
Cell: 650-823-8699
________________________________
From: Gordon Smith <go...@adobe.com>
To: "flex-dev@incubator.apache.org" <fl...@incubator.apache.org>
Sent: Monday, February 27, 2012 10:55 AM
Subject: RE: Code formatting for patch submissions
I wrote Adobe's coding guidelines for ActionScript and I noticed a few ways in which this formatting doesn't match what the framework's current conventions:
1. We wrap lines at 80 characters.
2. We make the first line of a multiline comment be /* or /** with no text.
3. We put an asterisk on every line of a multiline comment.
4. We line up the asterisks in a multiline comment.
5. We use two spaces after the asterisks so that the text starts at the same indent position as code.
- Gordon Smith, Adobe
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Sunday, February 26, 2012 2:50 PM
To: flex-dev@incubator.apache.org
Subject: Re: Code formatting for patch submissions
Hi,
> Which flex formatter properties file did you use to format the code
> example you made? I sent one in a previous thread, did you use that
> one or an Adobe one?
Just pushed the button in the preferences marked "Set to Adobe standards". I believe it has a couple of differences to what the "standards" are now but it's a good start.
Thanks,
Justin
RE: Code formatting for patch submissions
Posted by Gordon Smith <go...@adobe.com>.
I wrote Adobe's coding guidelines for ActionScript and I noticed a few ways in which this formatting doesn't match what the framework's current conventions:
1. We wrap lines at 80 characters.
2. We make the first line of a multiline comment be /* or /** with no text.
3. We put an asterisk on every line of a multiline comment.
4. We line up the asterisks in a multiline comment.
5. We use two spaces after the asterisks so that the text starts at the same indent position as code.
- Gordon Smith, Adobe
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Sunday, February 26, 2012 2:50 PM
To: flex-dev@incubator.apache.org
Subject: Re: Code formatting for patch submissions
Hi,
> Which flex formatter properties file did you use to format the code
> example you made? I sent one in a previous thread, did you use that
> one or an Adobe one?
Just pushed the button in the preferences marked "Set to Adobe standards". I believe it has a couple of differences to what the "standards" are now but it's a good start.
Thanks,
Justin
Re: Code formatting for patch submissions
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Which flex formatter properties file did you use to format the code example
> you made? I sent one in a previous thread, did you use that one or an Adobe
> one?
Just pushed the button in the preferences marked "Set to Adobe standards". I believe it has a couple of differences to what the "standards" are now but it's a good start.
Thanks,
Justin
Re: Code formatting for patch submissions
Posted by Omar Gonzalez <om...@gmail.com>.
>
> Does the property file help for IntelliJ or FDT? Someway to convert it to
> what they expect? (I'm not familiar with how they store formatting values.)
>
> Thanks,
> Justin
>
I'm not sure about FDT but for IntelliJ it doesn't really help I don't
think, at least I haven't looked at how the values are stored in IntelliJ.
I'd just use the FlexFormatter settings in my Flash Builder and replicate
the settings in the IntelliJ window. I know you can save different settings
in IntelliJ, in a quick search (
http://musingsofaprogrammingaddict.blogspot.com/2010/03/import-code-style-settings-into.html)
apparently they save them in XML so perhaps they can be translated in XML.
I can look at that later today in the evening.
Which flex formatter properties file did you use to format the code example
you made? I sent one in a previous thread, did you use that one or an Adobe
one?
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: Code formatting for patch submissions
Posted by Omar Gonzalez <om...@gmail.com>.
On Sun, Feb 26, 2012 at 2:46 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> > the coding conventions of Flex SDK are sometimes harmful in that they
> don't
> > distinguish between the purpose and style
> I agree (mostly). Everyone has their own ideas to how code should be
> formatted and consensus would be hard.
>
> Personally for example I much prefer the "one true brace" style for
> brackets and prefer tabs over spaces but the SDK is not coded that way.
>
> We have to live with what we currently have and that's formatted in a
> particular style which we should try to stick to.
>
> However I'm sure if enough people feel strongly about as aspect of it can
> be changed.
>
> Thanks,
> Justin
Well, just another thing to keep in mind, we've discussed having a commit
where we run the entire source through the formatting settings. So once we
do come to a consensus we should be able to automate the process of
formatting the code hopefully and format everything once so it can all be
uniform. I'm still for this and think its a good idea.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: Code formatting for patch submissions
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> the coding conventions of Flex SDK are sometimes harmful in that they don't
> distinguish between the purpose and style
I agree (mostly). Everyone has their own ideas to how code should be formatted and consensus would be hard.
Personally for example I much prefer the "one true brace" style for brackets and prefer tabs over spaces but the SDK is not coded that way.
We have to live with what we currently have and that's formatted in a particular style which we should try to stick to.
However I'm sure if enough people feel strongly about as aspect of it can be changed.
Thanks,
Justin
Re: Code formatting for patch submissions
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
I agree, I can't care less about the details. Basically my thinking is:
Take the current code and
find the most common denominator (that requires least fixing). Anyone
who does that gets
my vote :)
yours
Martin.
On 27/02/2012 07:37, Omar Gonzalez wrote:
>
> Code formatting is an area with a lot of contention and strong opinions. We
> can't dwell on too many arguments here because no matter what we decide on
> it is going to be a compromise from every developer for the greater good of
> the team and the source code. So I agree and why I said I care more that we
> have a convention and that it is followed. I care less about the minutia of
> the actual coding conventions. I just want the code to be easily legible
> and not full of 'clever' syntaxes.
>
> --
> Omar Gonzalez
> s9tpepper@apache.org
> Apache Flex PPMC Member
>
Re: Code formatting for patch submissions
Posted by Omar Gonzalez <om...@gmail.com>.
On Sun, Feb 26, 2012 at 2:32 PM, Left Right <ol...@gmail.com> wrote:
> I think that if I had to use Intelij for my day job, I'd quit, and the
> coding conventions of Flex SDK are sometimes harmful in that they don't
> distinguish between the purpose and style (e.g. comparing to null,
> converting instead of casting etc.). I expect that I won't be happy with
> the decision. I also expect that I will not convince anyone to follow what
> I think is proper. Therefore I'd settle for any convention. Just make it
> quick and never discuss it again :)
>
> Best.
>
> wvxvw
>
Code formatting is an area with a lot of contention and strong opinions. We
can't dwell on too many arguments here because no matter what we decide on
it is going to be a compromise from every developer for the greater good of
the team and the source code. So I agree and why I said I care more that we
have a convention and that it is followed. I care less about the minutia of
the actual coding conventions. I just want the code to be easily legible
and not full of 'clever' syntaxes.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: Code formatting for patch submissions
Posted by Left Right <ol...@gmail.com>.
I think that if I had to use Intelij for my day job, I'd quit, and the
coding conventions of Flex SDK are sometimes harmful in that they don't
distinguish between the purpose and style (e.g. comparing to null,
converting instead of casting etc.). I expect that I won't be happy with
the decision. I also expect that I will not convince anyone to follow what
I think is proper. Therefore I'd settle for any convention. Just make it
quick and never discuss it again :)
Best.
wvxvw
Re: Code formatting for patch submissions
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Also wanted to say I could live with the formatting that's in the
> FlexFormatter settings you used.
I also prefer spaces over tabs but Adobe policy seems to be spaces. (In my experience spaces tend to wonder off multiples of 4 over time and you get odd spacing).
Luckily most editors can convert on saving and most diff programs can ignore whitespace changes.
> My main thing is just that we have something and that we figure out the appropriate settings for IntelliJ,
> Flash Develop and FDT as well as Flash Builder.
Does the property file help for IntelliJ or FDT? Someway to convert it to what they expect? (I'm not familiar with how they store formatting values.)
Thanks,
Justin
Re: Code formatting for patch submissions
Posted by Omar Gonzalez <om...@gmail.com>.
Also wanted to say I could live with the formatting that's in the
FlexFormatter settings you used. My main thing is just that we have
something and that we figure out the appropriate settings for IntelliJ,
Flash Develop and FDT as well as Flash Builder. I'd suggest to everyone to
move to IntelliJ but that's just cause I'm a recent convert and I wish I
switched long ago. :) But we do want to make sure that all the major IDEs
can be set to appropriate formatting settings and that they're used on all
submitted patches.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: Code formatting for patch submissions
Posted by Omar Gonzalez <om...@gmail.com>.
>
> One thing I'd argue changing is code like this:
>
> if (some condition)
> a = 1;
> else
> b = 2;
>
> While it's compact the missing braces can (and often do) cause bugs when
> the code is modified.
>
> Thanks,
> Justin
>
>
I would have to agree. I tend to lean in the favor of legibility over
trying to make my code overly compact. There are going to be a lot of
people contributing to this code, hopefully, and we want to keep the code
we share with each other as easy to read as possible. I think we should
keep the curly braces here.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: Code formatting for patch submissions
Posted by David Francis Buhler <da...@gmail.com>.
FlexFormatter has an option that will add the missing curly braces.
to enable: Flex Formatter > Actionscript > tweaks > pre-formatting options
> select "add always" or "add smart"
Missing Curly Braces bothers me to no end.
> One thing I'd argue changing is code like this:
>
> if (some condition)
> a = 1;
> else
> b = 2;
>
> While it's compact the missing braces can (and often do) cause bugs when
> the code is modified.
>
> Thanks,
> Justin
>
>