On Jan 7, 2014, at 3:22 PM, Cameron McCormack wrote:
> Patrick McManus wrote:
>> Typically I have to choose between
>> 1] 80 columns
>> 2] descriptive and non-abbreviated naming
>> 3] displaying a logic block without scrolling
>>
>> to me, #1 is the least valuable.
>
> Thoroughly agree.
I
Chiming in a little late:
On Jan 6, 2014, at 6:35 PM, Joshua Cranmer 🐧 wrote:
> I find prefixing member variables with 'm' to be useful, although I dislike
> using it in POD-ish structs where all the members are public.
Fully agreed, and IMO the style guide should be changed to include this.
I don't use Terminals for programming, I have the space for 100 chars. I
also usually don't open more than one window at a time. I usually just
switch between files very quickly if I need to correlate something.
Everytime single time I create a patch that touches a lot of code Gecko, I
feel like 80
re 80char vs 100chars:
I am for 80 chars.
If the argument for expanding to 100 or more is that screen is getting wider,
then the benefit of wide screen is able to fit multiple terminals in one
window. For normal workflow, I'd split my windows into two or terminals,
depending on what I am doing
Count me as another person in favor of an 80-column hard limit because
of being able to open two files side-by-side with that limit, but not
anything wider (even 100 is too wide). I spend a lot of time with an
editor window tiled against a whole bunch of MXR tabs.
I either don't care or can l
On 1/7/2014, 3:46 PM, Mike Hoye wrote:
2 v. 4 spaces: more on that shortly.
An update on the research: Earlier, I said "four spaces" flat out, based
on some conversations with researchers, but since then all the research
I've been able to track down seems to cite the same paper. That paper
On 09/01/14 06:57, Adam Roach wrote:
> Automated wrapping to a column width is less than optimal. If you look
> back at bz's example about how he would chose to wrap a specific
> conditional, it's based on semantic intent, not the language syntax. By
> and large, this goes to author's intent and hi
On 08/01/14 11:49, Nicholas Nethercote wrote:
> If you're just distinguishing members, then |foo_| is good. But if
> you're distinguishing parameters and globals/statics as well (which I
> think is a good idea), then mFoo/aFoo/gFoo/sFoo makes more sense.
If you want to be precise you would use thi
On 2014-01-08, at 10:06, Adam Roach wrote:
> The second is that we need to be careful if we decide to run a reformatter
> over the code wholesale, since you can actually lose useful information about
> author's intent. I'm not the first to raise that point in this discussion;
> I'm simply agr
On 1/8/14 12:03, Martin Thomson wrote:
On 2014-01-08, at 09:57, Adam Roach wrote:
Automated wrapping to a column width is less than optimal. If you look back at
bz's example about how he would chose to wrap a specific conditional, it's
based on semantic intent, not the language syntax. By an
On 2014-01-08, at 09:57, Adam Roach wrote:
> Automated wrapping to a column width is less than optimal. If you look back
> at bz's example about how he would chose to wrap a specific conditional, it's
> based on semantic intent, not the language syntax. By and large, this goes to
> author's in
On 1/8/14 11:28, Martin Thomson wrote:
So maybe this can bifurcate the bike shedding discussion further: do you want
to have a tool wrap to X, or do you want a tool to block patches that exceed X?
Automated wrapping to a column width is less than optimal. If you look
back at bz's example abou
On 2014-01-07, at 17:49, Joshua Cranmer wrote:
> Since I'm seeing a lot of people advocating that the wrap margin should be
> 100,
> let me reiterate
> David Baron's comment that the wrap margin must either be 80 or infinite […]
I have always preferred no wrapping, with the line length limit b
On 07/01/14 22:26, Jeff Walden wrote:
> which was unreadable. You simply can't easily skim and see where the body
> starts and where the condition ends, even with braces. We shoved the opening
> brace to its own line:
>
> if (somethingHere() &&
> somethingElse())
> {
> doSomething();
>
On 1/6/2014 7:38 PM, L. David Baron wrote:
> I tend to think that we should either:
> * stick to 80
> * require no wrapping, meaning that comments must be one paragraph
>per line, boolean conditions must all be single line, and assume
>that people will deal, using an editor that handles s
On 1/7/14 7:57 PM, Mark Finkle wrote:
Changing the line length policy would also avoid needing to wrap the multiple
conditions onto separate lines.
I often wrap conditions just to make the more readable... Something like
this:
if ((x || y) && (z || w))
is a lot less readable for me than:
Agreed. In /mobile JS code we favor wrapping >80 characters. 100 seems
reasonable to me.
- Original Message -
> I strongly prefer at least a 100 character per line limit. Technology
> marches on.
> On Mon, Jan 6, 2014 at 9:23 PM, Karl Tomlinson wrote:
> > L. David Baron writes:
> >
>
> One reason I've seen 2 preferred to 4 (apart from keeping line lengths
> down) is that:
> if (somethingHere() &&
> somethingElse())
> doSomething();
> is less clear about what's condition and what's body the if body is than:
> if (somethingHere() &&
> somethingElse())
> doSomething();
Changin
FWIW, WebGL and GLContext do this for the same reasons.
-jgilbert
- Original Message -
From: "Jeff Walden"
To: dev-platform@lists.mozilla.org
Sent: Tuesday, January 7, 2014 2:26:46 PM
Subject: Re: Mozilla style guide issues, from a JS point of view
On 01/07/2014 02:23 PM, Bor
Speaking of the troubles with 80 character line lengths, I find I often
need to write variable and function declaration/calls like this:
https://hg.mozilla.org/mozilla-central/file/8f1c9cdedba5/layout/style/nsCSSParser.cpp#l429
https://hg.mozilla.org/mozilla-central/file/8f1c9cdedba5/layout/styl
Patrick McManus wrote:
Typically I have to choose between
1] 80 columns
2] descriptive and non-abbreviated naming
3] displaying a logic block without scrolling
to me, #1 is the least valuable.
Thoroughly agree.
___
dev-platform mailing list
dev
On 1/7/2014, 5:59 PM, Martin Thomson wrote:
On 2014-01-07, at 14:52, Ehsan Akhgari wrote:
I don't have any opinions on gFoo.
Aside from “should not exist” ?
I won't object either way!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 2014-01-07, at 14:52, Ehsan Akhgari wrote:
> I don't have any opinions on gFoo.
Aside from “should not exist” ?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 1/7/2014, 5:49 PM, Nicholas Nethercote wrote:
On Tue, Jan 7, 2014 at 11:28 AM, Benjamin Smedberg
wrote:
I don't have strong opinions about our current mFoo naming
versus the google-like member_ naming.
If you're just distinguishing members, then |foo_| is good. But if
you're distinguishing
On Tue, Jan 7, 2014 at 11:28 AM, Benjamin Smedberg
wrote:
> I don't have strong opinions about our current mFoo naming
> versus the google-like member_ naming.
If you're just distinguishing members, then |foo_| is good. But if
you're distinguishing parameters and globals/statics as well (which I
On 01/07/2014 02:23 PM, Boris Zbarsky wrote:
> One reason I've seen 2 preferred to 4 (apart from keeping line lengths down)
> is that:
>
> if (somethingHere() &&
> somethingElse())
> doSomething();
>
> is less clear about what's condition and what's body the if body is than:
>
>
Typically I have to choose between
1] 80 columns
2] descriptive and non-abbreviated naming
3] displaying a logic block without scrolling
to me, #1 is the least valuable.
On Tue, Jan 7, 2014 at 4:51 PM, Jim Porter wrote:
> On 01/06/2014 08:23 PM, Karl Tomlinson wrote:
>
>> Yes, those are th
On 01/06/2014 08:23 PM, Karl Tomlinson wrote:
Yes, those are the sensible options.
Wrapping at > 80 columns just makes things worse for those that
like to save some screen room for something else, view code on a
mobile device, etc.
I for one prefer wrapping at 80 columns because with my font s
On 1/7/2014, 2:29 PM, Martin Thomson wrote:
On 2014-01-07, at 11:28, Benjamin Smedberg wrote:
Especially for new contributors we shouldn't assume that most editors can do
this correctly. I personally think that the risk of introducing a new member
and then having locals shadow members is rea
On 1/7/14 11:23 AM, Neil wrote:
> Martin Thomson wrote:
>
>> in JS, a case that I’ve encountered several times:
>> _classMethodName: function
>> ReasonableClassName__classMethodName(argument1, argument2) {
>>
> I thought that our debugging story had improved sufficiently that we
> didn't
On Wed, Jan 8, 2014 at 9:46 AM, Mike Hoye wrote:
> On 1/7/2014, 3:22 PM, Adam Roach wrote:
>
>>
>> Since people are introducing actual research information here, let's run
>> some numbers. According to Paterson et. al. [1], reading comprehension
>> speed is actively hindered by lines that are eit
On 1/7/2014, 3:22 PM, Adam Roach wrote:
Since people are introducing actual research information here, let's
run some numbers. According to Paterson et. al. [1], reading
comprehension speed is actively hindered by lines that are either too
short or too long, which they define as 9 picas (1.5
On 1/7/14 14:23, Boris Zbarsky wrote:
One reason I've seen 2 preferred to 4 (apart from keeping line lengths
down)...
Thanks. I was just about to raise the issue that choosing four over two
has no identified benefits, and only serves to exacerbate *both* sides
of the argument over line length
On 1/7/14 2:29 PM, Mike Hoye wrote:
- Indent with 4 spaces,
Mike, do you have the background on why 4 is preferred to 2? The things
you cite don't seem to differentiate between these two options...
One reason I've seen 2 preferred to 4 (apart from keeping line lengths
down) is that:
if
On 1/7/14 12:16, Martin Thomson wrote:
On 2014-01-06, at 19:28, Patrick McManus wrote:
I strongly prefer at least a 100 character per line limit. Technology
marches on.
Yes. I’ve encountered too many instances where 80 was not enough.
Since people are introducing actual research informatio
On 2014-01-07, at 11:28, Benjamin Smedberg wrote:
> Especially for new contributors we shouldn't assume that most editors can do
> this correctly. I personally think that the risk of introducing a new member
> and then having locals shadow members is real enough that we should somehow
> distin
On 1/7/2014, 10:44 AM, Gervase Markham wrote:
It would be very interesting for someone to see if any of the
references Mike Hoye gives explain _which_ types of change lead to
loss of productivity. For example, it could be that brace style does,
and line length does not.
I've been digging i
On 1/7/2014 1:16 PM, Martin Thomson wrote:
Hungarian notation = unnecessary and costly (technology fixed this problem
years ago, for member vs. local most editors can do syntax highlighting; plus,
it’s easier to type and read without it).
Especially for new contributors we shouldn't assume that
Martin Thomson wrote:
in JS, a case that I’ve encountered several times:
_classMethodName: function ReasonableClassName__classMethodName(argument1, argument2) {
I thought that our debugging story had improved sufficiently that we
didn't need these fake function names any more.
--
On Tuesday 2014-01-07 10:23 -0800, Bobby Holley wrote:
> On Tue, Jan 7, 2014 at 9:38 AM, Adam Roach wrote:
>
> > On 1/7/14 03:07, Jason Duell wrote:
> >
> >> Yes--if we jump to >80 chars per line, I won't be able to keep two
> >> columns open in my editor (vim, but emacs would be the same) on my
On Tue, Jan 7, 2014 at 9:38 AM, Adam Roach wrote:
> On 1/7/14 03:07, Jason Duell wrote:
>
>> Yes--if we jump to >80 chars per line, I won't be able to keep two
>> columns open in my editor (vim, but emacs would be the same) on my laptop,
>> which would suck.
>>
>> (Yes, my vision is not what it u
On 2014-01-06, at 19:28, Patrick McManus wrote:
> I strongly prefer at least a 100 character per line limit. Technology
> marches on.
Yes. I’ve encountered too many instances where 80 was not enough.
Good identifier names are hugely important, no matter what the language, which
means sometime
On 1/7/14 03:07, Jason Duell wrote:
Yes--if we jump to >80 chars per line, I won't be able to keep two
columns open in my editor (vim, but emacs would be the same) on my
laptop, which would suck.
(Yes, my vision is not what it used to be--I'm using 10 point font.
But that's not so huge.)
I
On 01/07/2014 02:20 AM, Ms2ger wrote:
> Based on the discussion in #jsapi yesterday, I'm not sure that "most JS
> hackers" is necessarily accurate.
I think there's a rough consensus. And I'd note only a few of us were really
active in that conversation, and I'm going somewhat off memory of what
On Monday, January 6, 2014 6:46:49 PM UTC-6, Jeff Walden wrote:
> I'm writing this list, so obviously I'm choosing what I think is on it. But
> I think there's rough consensus on most of these among JS hackers.
>
>
>
> JS widely uses 99ch line lengths (allows a line-wrap character in 100ch
>
On 07/01/14 00:46, Jeff Walden wrote:
> JS widely uses 99ch line lengths (allows a line-wrap character in
> 100ch terminals). Given C++ symbol names, especially with templates,
> get pretty long, it's a huge loss to revert to 80ch because of how
> much has to wrap. Is there a reason Mozilla could
On 01/06/2014 06:35 PM, Joshua Cranmer 🐧 wrote:
Side-by-side diffs are one use case I can think of. Another is that some
people prefer to develop by keeping tiled copies of windows; wider lines
reduce the number of tiled windows that one can see.
Yes--if we jump to >80 chars per line, I won't
On 01/07/2014 01:46 AM, Jeff Walden wrote:
I don't think most JS hackers care for abuse of Hungarian notation
for scope-based (or const) naming. Every member/argument having a
capital letter in it surely makes typing slower. And extra noise in
every name but locals seems worse for new-contribut
On 01/06/2014 08:35 PM, Joshua Cranmer 🐧 wrote:
> And a '_' at the end of member names requires less typing than 'm' + capital
> letter?
This started, and still largely is, an Ion convention. Lots of existing code
doesn't use it, and I haven't much worked on code that does. But as I said,
I'm
I strongly prefer at least a 100 character per line limit. Technology
marches on.
On Mon, Jan 6, 2014 at 9:23 PM, Karl Tomlinson wrote:
> L. David Baron writes:
>
> > I tend to think that we should either:
> > * stick to 80
> > * require no wrapping, meaning that comments must be one paragrap
On 1/6/2014 6:46 PM, Jeff Walden wrote:
I'm writing this list, so obviously I'm choosing what I think is on it. But I
think there's rough consensus on most of these among JS hackers.
JS widely uses 99ch line lengths (allows a line-wrap character in 100ch
terminals). Given C++ symbol names, e
L. David Baron writes:
> I tend to think that we should either:
> * stick to 80
> * require no wrapping, meaning that comments must be one paragraph
>per line, boolean conditions must all be single line, and assume
>that people will deal, using an editor that handles such code
>usefu
On Mon, Jan 6, 2014 at 5:38 PM, L. David Baron wrote:
>>
> So if we're switching to 99 or 100, I'd like to understand how you
> picked that number and have confidence that it's not just going to
> keep going up.
SpiderMonkey's used 99 for years and years without anyone (AFAIK)
arguing that it be
On Monday 2014-01-06 18:46 -0600, Jeff Walden wrote:
> I'm writing this list, so obviously I'm choosing what I think is on it. But
> I think there's rough consensus on most of these among JS hackers.
>
> JS widely uses 99ch line lengths (allows a line-wrap character in 100ch
> terminals). Give
On 1/6/14 7:46 PM, Jeff Walden wrote:
Any style checker that checks both indentation and bracing (of course we'll
have one, right?)
If we have such a checker, and if it turns the tree orange on
violations, then I can see relaxing the requirement for braces,
probably. That requirement is the
On 01/07/2014 02:46 AM, Jeff Walden wrote:
I'm writing this list, so obviously I'm choosing what I think is on it. But I
think there's rough consensus on most of these among JS hackers.
JS widely uses 99ch line lengths (allows a line-wrap character in 100ch
terminals). Given C++ symbol names
On Tue, Jan 7, 2014 at 1:46 PM, Jeff Walden wrote:
> JS widely uses 99ch line lengths (allows a line-wrap character in 100ch
> terminals). Given C++ symbol names, especially with templates, get pretty
> long, it's a huge loss to revert to 80ch because of how much has to wrap.
> Is there a reaso
On 1/6/14, 4:46 PM, Jeff Walden wrote:
JS widely uses 99ch line lengths (allows a line-wrap character in 100ch
terminals). Given C++ symbol names, especially with templates, get pretty
long, it's a huge loss to revert to 80ch because of how much has to wrap. Is
there a reason Mozilla couldn'
I'm writing this list, so obviously I'm choosing what I think is on it. But I
think there's rough consensus on most of these among JS hackers.
JS widely uses 99ch line lengths (allows a line-wrap character in 100ch
terminals). Given C++ symbol names, especially with templates, get pretty
long
59 matches
Mail list logo
