On 2/27/12 1:46 PM, "olegsivo...@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 so
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
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 typewrite
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 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 du
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
fit
On Mon, Feb 27, 2012 at 12:03 PM, Carol Frampton wrote:
>
>
> On 2/27/12 1 :55PM, "Gordon Smith" 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
---
>From: Justin Mclean [mailto:jus...@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
>>
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 go
flex-dev@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
asssoftware.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
> on
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
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
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.
On 2/26/12 8:37 PM, "David Francis Buhler" 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 differ
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 c
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
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
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 wrote:
> Hi,
>
>> Which flex formatter properties file did you use to
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
On Sun, Feb 26, 2012 at 2:46 PM, Justin Mclean 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 ha
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" sty
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
On Sun, Feb 26, 2012 at 2:32 PM, Left Right 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 castin
>
> 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 valu
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
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
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 b
>
> 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 leg
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
29 matches
Mail list logo
