Re: Mozilla style guide issues, from a JS point of view
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 also agree with this. Perhaps a compromise might be that we should aim for 80 columns except for cases where this would hurt readability, but have a hard limit at 100 columns. Given how verbose C++ is, an 80 column limit (for me) often ends up hurting readability more than it helps. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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. > The use of 'a' for arguments is where I am least consistent, especially as I > extremely dislike it being used for an outparam return value That also bothers me. I'd support adding an 'o' prefix for outparams. > I've never found much use for the 's', 'g', and 'k' prefixes, although that > may just as well be because I've never found much use for using those types > of variables in the first place (or when I do, it's because I'm being > dictated by other concerns instead, e.g., type traits-like coding or C++11 > polyfilling). I don't see the use in distinguishing between 's' and 'g'. They're both potentially dangerous globally-shared data, and that's the most important information the reader should know. (Except if they're immutable, of course, but then presumably they'd have a 'k' prefix.) We could classify them both as 'g', but considering the number of bugs I've seen stemming from unprotected access to these kinds of variables, I would support a more verbose and distinctive prefix like 'unsafe'. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 chars is just not enough. My experience is obviously kind of
skewed, because I mostly edit function definitions in away that makes them
longer, i.e. replace JS::Value with JS::Handle. I feel like a
thousand times I just barely miss the 80 char limit and I have to start
wrapping some arguments around, which can be really annoying, because
suddenly you also have to move something else etc.
I don't really care about 2/4 spaces, I just press tab anyway.
On Fri, Jan 17, 2014 at 3:03 AM, wrote:
> 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, so I don't see any benefit for
> increasing the limit.
>
>
> re braces for single statement:
>
> I am for always braces.
>
> If multi-statement logical statement requires braces pair, why make
> exception to the single logical branch?
>
> if (...)
> do_stuff
>
> vs
>
> if (...) {
> do_stuff
> }
>
> and if I need to add more statements (like adding debug), I don't need to
> go back and add { } again which can be as difficult as adding { } in the
> first place (but that's a one-time cost). I am not sure why this is not a
> problem... I know, it sounds lazy, but since we are mentioning
> productivity
>
>
> re 2 spaces vs 4 spaces:
>
> I'd keep with two-space.
>
> I come from Python world and after working on Firefox for a while I am
> used to two-space instead of four-space in Firefox.
>
> Does four-space increase productivity? My take on this is that not
> necessarily and productivity depends on the tool the developer is using. If
> you use vim you can set the tab indentation to four spaces. You can also
> set language-specific indentation. I can't speak of other editors and IDEs
> out there and we certainly can't make everyone happy.
>
> Chromium has the following style guide:
>
> "Python code should follow PEP-8, except that Chromium uses two-space
> indentation instead of four-space indentation, and it uses MixedCase for
> method names and function names instead of lower_case_with_underscores"
>
> I am not saying we have to stick with two-space because Chromium uses
> two-space since Linux kernel is 8-space, but two-space is not rare at all
> (I am not sure Chromium's decision is influenced by people who started
> Chrome in the first place, as they had/have been firefox contributors).
>
> Finally, another thing to consider when we write a style checker is to
> consider this way of wrapping lines:
>
> const SOME_REGEX_CONSTANT = new RegExp("^(str1|str2" +
>"str3|str4");
>
> const SOME_KEYWORD_TO_SET = "hello world" +
> "what is going on?"
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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, so I don't see any benefit for increasing the
limit.
re braces for single statement:
I am for always braces.
If multi-statement logical statement requires braces pair, why make exception
to the single logical branch?
if (...)
do_stuff
vs
if (...) {
do_stuff
}
and if I need to add more statements (like adding debug), I don't need to go
back and add { } again which can be as difficult as adding { } in the first
place (but that's a one-time cost). I am not sure why this is not a problem...
I know, it sounds lazy, but since we are mentioning productivity
re 2 spaces vs 4 spaces:
I'd keep with two-space.
I come from Python world and after working on Firefox for a while I am used to
two-space instead of four-space in Firefox.
Does four-space increase productivity? My take on this is that not necessarily
and productivity depends on the tool the developer is using. If you use vim you
can set the tab indentation to four spaces. You can also set language-specific
indentation. I can't speak of other editors and IDEs out there and we certainly
can't make everyone happy.
Chromium has the following style guide:
"Python code should follow PEP-8, except that Chromium uses two-space
indentation instead of four-space indentation, and it uses MixedCase for method
names and function names instead of lower_case_with_underscores"
I am not saying we have to stick with two-space because Chromium uses two-space
since Linux kernel is 8-space, but two-space is not rare at all (I am not sure
Chromium's decision is influenced by people who started Chrome in the first
place, as they had/have been firefox contributors).
Finally, another thing to consider when we write a style checker is to consider
this way of wrapping lines:
const SOME_REGEX_CONSTANT = new RegExp("^(str1|str2" +
"str3|str4");
const SOME_KEYWORD_TO_SET = "hello world" +
"what is going on?"
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 live with everything else under discussion. (If there were a chance of getting rid of the useless scoping prefixes on *everything*, as a big bang rewrite-the-entire-tree change, I would be for it. But somehow I don't think that's going to happen.) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 says that two to four spaces of indentation results in better code comprehension than zero (obvs.) or 6+ spaces. That paper is here: http://www.cs.umd.edu/~ben/papers/Miara1983Program.pdf It also says that as long as it's consistent, block style doesn't matter, but that's not the most interesting thing here. There are two things I've found while digging this stuff out that are really, really cool. First of all: Perceived efficiency and real efficiency aren't the same thing at all. People asked to rate what codebase they found most pleasant and efficient to work with, consistently rating 6 or more spaces very higher than 2-4 spaces, but when you put those people in front of an eye tracker and a stopwatch, what they perceive as best isn't what actually works best. It echoes this classic Ask Tog article from the 1989, about clicking icons with mouse v. keyboard shortcuts - People who think the keyboard is faster are measurably wrong, because their brains actually don't remember the time it takes to recall a key sequence, instead of clicking a button. http://www.asktog.com/TOI/toi06KeyboardVMouse1.html The other thing that's probably more important from a community engagement or developer-migration perspective is that real complexity and perceived complexity are also two entirely different things. A dirt-simple program with crappy formatting, or even just a new codebase in a format that's new to you, will be perceived as much more complex and _become much harder to understand_ than a genuinely complicated program with a clean, well-structured codebase. Which is all to say that I think this is kind of important. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 his understanding of the > problem at hand. It's not the kind of thing that can be derived > mechanically. I'm advocating using clang-format to automatically wrap. The author can force a line wrap by adding an empty comment // at the end of a line. This both records the author's intent and makes it visible. Using either no line wrapping or automatic line wrapping means you can use a proportional font. Anthony ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 this->member and MyClass::static_variable which is a language feature rather than a local convention. Anthony ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 agreeing with it. I canāt disagree with the point itself, though I will say that I donāt agree itās a worthwhile point. There are better ways to make intent clear. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 and large, this goes to author's intent and his understanding of the problem at hand. It's not the kind of thing that can be derived mechanically. From that I infer that you would prefer to leave wrapping choices to individuals. Thatās in favour of the latter option: enforce line length, but donāt reformat to it. My observation has two key implications. That's the first. 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 agreeing with it. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 intent and his understanding of the problem at hand. It's not the > kind of thing that can be derived mechanically. >From that I infer that you would prefer to leave wrapping choices to >individuals. Thatās in favour of the latter option: enforce line length, but >donāt reformat to it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 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 his understanding of the problem at hand. It's not the kind of thing that can be derived mechanically. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 being a
guideline that encourages use of splitting in the following form:
-pc._localIdp.appendIdentityToSDP(sdp, pc._impl.fingerprint, function(sdp,
assertion) {
+let fp = pc._impl.fingerprint;
+pc._localIdp.appendIdentityToSDP(sdp, fp, function(sdp, assertion) {
Rather than forced wrapping:
-pc._localIdp.appendIdentityToSDP(sdp, pc._impl.fingerprint, function(sdp,
assertion) {
+pc._localIdp.appendIdentityToSDP(sdp,
+ pc._impl.fingerprint,
+ function(sdp, assertion) {
The problem there being that the only realistic option for handling this is
checking.
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?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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();
> }
AIUI, many style guides which ask for the brace to be on the end of the
"if" have an exception for multi-line conditionals, exactly as you state.
Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 such code >usefully 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 with a self-demonstrating response. I once suggested a wider wrap margin as a compromise years ago, but I have come around to the viewpoint that the only acceptable wrap margins are 80 and infinite. The absolute worst visual display to read is when you have text that contains a mixture of soft wraps (caused by lines longer than your display) with hard wraps (caused by a max-line-length requirement). The text in this post is set up to emulate the display of text that has a hard wrap at around the 100th character being displayed on an 80-character terminal window. Thus, this is the code that people using 80-character terminal windows will be subjected to in places that have heavy paragraph-style text (e.g., README files, documentation comments, or even really long regular comment blocks). Now, you can argue that people should just resize their windows to be . I suspect that many of the people making this arguments are people who use GUI editors that have 120+-character viewports for code, arguing for the ability to utilize what it is often just dead whitespace in their editor and frustrated that people using "older" technology are limiting use of this space. As one who uses 80-character terminals heavily, I can report that changing the size of the terminal is generally not a viable option. Many people who use smaller terminal sizes fill up the screen real estate by tiling the terminals. On smaller resolutions and larger font sizes, changing the screen size even to 100 makes it impossible to tile more than two windows horizontally on the screen: changing the screen size is impossible. Furthermore, the default size for a terminal has been decided on by universal convention to be 80x24: any would-be contributor to Mozilla who uses the default-sized terminals would be forced to either put up with the painful reading of poorly-wrapped lines or to figure out how to retool their entire workflow just to be able to contribute--and I suspect that many would instead find themselves driven away. Infinitely-long lines do not have the same problems that wrapping at any value > 80 does: most editors are capable of soft-wrapping them to some degree of legibility. The problem isn't that some lines have to be wrapped as much as it is that the lines are wrapped at completely wrong places. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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: if ((x || y) && (z || w)) once the actual expressions around || get a bit longer, even if the former isn't hitting a line length limit. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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: > > > > > 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 > > > usefully > > > > 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. > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
> 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(); Changing the line length policy would also avoid needing to wrap the multiple conditions onto separate lines. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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, 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:
>
> if (somethingHere() &&
> somethingElse())
> doSomething();
>
> but this would obviously also be affected by the bracing policy.
Regarding the effect of the bracing policy, SpiderMonkey used to have
if (somethingHere() &&
somethingElse()) {
doSomething();
}
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();
}
It doesn't seem to me that the four-space issue here is helped by braces in
end-of-line configuration.
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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/style/nsCSSParser.cpp#l2182 I think this kind of wrapping, where if you can't fit the first argument on the line then you put it on a new line, but leave the opening paren on the first line, is reasonably common. I tend to align the arguments so that they right align with the 80 character column (or somewhere close), although that then can result in unnecessary churn when renaming/adding/removing arguments. It would be good if the style guide could say what to do here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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
Re: Mozilla style guide issues, from a JS point of view
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 parameters and globals/statics as well (which I think is a good idea), then mFoo/aFoo/gFoo/sFoo makes more sense. And because I think that distinguishing parameters is at least very useful, I think we should maintain mFoo and aFoo. And sFoo for static members. I don't have any opinions on gFoo. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 think is a good idea), then mFoo/aFoo/gFoo/sFoo makes more sense. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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:
>
> if (somethingHere() &&
> somethingElse())
> doSomething();
>
> but this would obviously also be affected by the bracing policy.
Regarding the effect of the bracing policy, SpiderMonkey used to have
if (somethingHere() &&
somethingElse()) {
doSomething();
}
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();
}
It doesn't seem to me that the four-space issue here is helped by braces in
end-of-line configuration.
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 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 settings, I > can have 3 buffers open side-by-side. I generally find that a lot more > useful than the vertical space that would be saved by wrapping at, say, 100 > columns. > > - Jim > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 settings, I can have 3 buffers open side-by-side. I generally find that a lot more useful than the vertical space that would be saved by wrapping at, say, 100 columns. - Jim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 real enough that we should somehow distinguish them. I don't have strong opinions about our current mFoo naming versus the google-like member_ naming. I have a tool for that: static analysis tools usually have a shadowing detection function. But many people don't have those tools, so this is not a good argument. (Note that we don't even turn on -Wshadow currently) Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 need these fake function names any more.
>
Yup. You shouldn't need to use named function expressions to get useful
stack traces anymore.
At least in devtools, new files don't use them and there are bugs open
for removing them in existing files.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 either too short or too long, >> which they define as 9 picas (1.5 inches) and 43 picas (~7 inches), >> respectively. Comprehension is significantly faster at 19 picas (~3 >> inches). [...] >> [1] http://psycnet.apa.org/journals/xge/27/5/572/ >> > > I found some other citations about this as well - > http://www.humanfactors.com/downloads/feb03.asp#kath among others - but > they all measure people reading English, not code. > Yes, it's not clear that those English results would carry over. For one thing, when reading English text almost every line is going to be close to the maximum line length, but not so in code. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 inches) and 43 picas (~7 inches), respectively. Comprehension is significantly faster at 19 picas (~3 inches). [...] [1] http://psycnet.apa.org/journals/xge/27/5/572/ I found some other citations about this as well - http://www.humanfactors.com/downloads/feb03.asp#kath among others - but they all measure people reading English, not code. I haven't been able to find any that are specifically on-point for coding, but I'm still looking. 2 v. 4 spaces: more on that shortly. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 limits. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 (somethingHere() && somethingElse()) doSomething(); is less clear about what's condition and what's body the if body is than: if (somethingHere() && somethingElse()) doSomething(); but this would obviously also be affected by the bracing policy. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 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 inches) and 43 picas (~7 inches), respectively. Comprehension is significantly faster at 19 picas (~3 inches). Using the default themes that ship with the OS X "Terminal" app, an 80-character-wide terminal is on the order of 4 inches wide on a 15-inch monitor. 100 columns pushes this to nearly 5 inches. Now, I'm not arguing for a 60-character line length here. However, it would seem that moving from 80 to 100 is going in the wrong direction for comprehension speed. [1] http://psycnet.apa.org/journals/xge/27/5/572/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 > distinguish them. I don't have strong opinions about our current mFoo naming > versus the google-like member_ naming. I have a tool for that: static analysis tools usually have a shadowing detection function. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 into the research style and formatting questions a bit, and this is what I have so far. Short version: - Indent with 4 spaces, - use CamelCase, - bracing style doesn't matter, - consistency is The Most Important Thing. Those are all consistently-replicated results. I don't have anything about line-length yet; I'm working on it. The details: On Spacing and indentation: Steve McConnell, in his book "Code Complete", says that "S ubjects scored 20 to 30 percent higher on a test of comprehension when programs had a two-to-four-spaces indentation scheme than they did when programs had no indentation at all. [...] The study concluded that two-to-four-space indentation was optimal. Interestingly, many subjects in the experiment felt that the six-space indentation was easier to use than the smaller indentations, even though their scores were lower. Thatās probably because six space indentation looks pleasing. But regardless of how pretty it looks, six-space indentation turns out to be less readable. This is an example of a collision be tween aesthetic appeal and readability." I've ordered a copy of his book, to figure out what the original source material actually says, but my understanding is that Python standardized on four-space indentation because of these results. Brace style: McConnell suggests - citing the Soloway and Ehrlich paper I mentioned, and others, that the specific brace style hasn't been demonstrated to matter all that much, provided it is always used consistently. Inconsistent bracing (exactly like every other inconsistently-applied coding style...) is what sends your thought process off into a ditch. On CamelCase v. underscore_delimited variable naming and comprehension: Bonita Sharif and Jonathan Maletic at Kent State have concluded that - with some caveats about novice programmers - there's not a big difference in comprehension and accuracy between the two. That paper is here: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf However, a related paper available here - http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5090039 - (don't have the full paper, sorry) concludes that among experienced programmers, CamelCase, not under_score, is measurably the right thing. So, there you go. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 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 distinguish them. I don't have strong opinions about our current mFoo naming versus the google-like member_ naming. Braces always = net win. Consistency + bug resilience > any aesthetic preference (which is trained anyway). It's not really a question of aesthetic preference. It's a question of reducing the vertical size of a method so that more of it fits on screen, especially when dealing with small error-handling paths. But we've had this conversation twice before, and Brendan decided that the always-braced style was the one we were going to use. So, despite it being not my personal preference, it's already settled and not worth reopening ;-) Hereās a few other things that I think should be added: function and file length limits: I think that 32 lines is enough for JS, and maybe 50 for C/C++ due to the increased need for error checking stuff. 1000 lines is enough for any single class/file. Iām certain others will want much longer :) Why so short? Function names are great just-in-time help, and long functions suffer from tl;cr (too long; canāt read). cyclomatic complexity limits: I like 8 for JS and probably 15 for C/C++ due to the impact of error checking. Again, Iām sure others will want more. The style guide is *mostly* a place to describe existing practice and formatting conventions. Your proposal here isn't in scope for the current discussion, nor something that at all describes current practice. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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.
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 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'm not just sympathetic to this argument; I've made it myself in other > > venues. Put me down as emphatically agreeing. > > > > Me too. With the font size that works for me, I can do 2 side-by-side > columns with 80 chars, but not 100. Same for me, for my laptop display. On my external monitors (office and home; different sizes), I can fit two at 100, but only barely so for my external monitor at home, and it might not stay that way the next time the available fonts change or font rasterization changes and I have to reconfigure. (The reality for me is that I don't use side-by-side much when writing code, but I do when doing code reviews.) -David -- š L. David Baron http://dbaron.org/ š š¢ Mozilla https://www.mozilla.org/ š Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 used to be--I'm using 10 point font. But >> that's not so huge.) >> > > I'm not just sympathetic to this argument; I've made it myself in other > venues. Put me down as emphatically agreeing. > Me too. With the font size that works for me, I can do 2 side-by-side columns with 80 chars, but not 100. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 sometimes that you need three words. With a meagre indent of 3 levels,
having to wrap to make a line fit 80 columns hurts readability far worse:
PeerConnectionIdp peerConnection =
PeerConnectionIdp::CreateInstance(domain, type);
Or in JS, a case that Iāve encountered several times:
_classMethodName: function
ReasonableClassName__classMethodName(argument1, argument2) {
BTW, @12pt, emacs shows 360 columns on my 27" monitor (easily 4x80), on my 13"
one, it shows 233. That seems plenty enough to me.
On the other points:
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).
Braces always = net win. Consistency + bug resilience > any aesthetic
preference (which is trained anyway).
Hereās a few other things that I think should be added:
function and file length limits:
I think that 32 lines is enough for JS, and maybe 50 for C/C++ due to the
increased need for error checking stuff.
1000 lines is enough for any single class/file.
Iām certain others will want much longer :) Why so short? Function names are
great just-in-time help, and long functions suffer from tl;cr (too long; canāt
read).
cyclomatic complexity limits:
I like 8 for JS and probably 15 for C/C++ due to the impact of error checking.
Again, Iām sure others will want more.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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'm not just sympathetic to this argument; I've made it myself in other venues. Put me down as emphatically agreeing. -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 others have said in the past. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 > 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't increase to 99 or 100? Viewability on-screen > seems pretty weak in this era of generally large screens. Printability's a > better argument, but it's unclear to me files are printed often enough for > this to matter. I do it one or two times a year, myself, these days. > > > > 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-contributor readability. Personally this doesn't bother > me much (although "aCx" will always be painful compared to "cx" as two no-cap > letters, I'm sure), but others are much more bothered. > > > > JS people have long worked without bracing single-liners. With any style > guide's indentation requirements, they're a visually redundant waste of > space. Any style checker that checks both indentation and bracing (of course > we'll have one, right?), will warn twice for the error single-line bracing > prevents. I think most of us would discount the value of being able to add > more to a single-line block without changing the condition line. So I'm > pretty sure we're all dim on this one. > > > > Skimming the rest of the current list, I don't see anything that would > obviously, definitely, be on the short list of complaints for SpiderMonkey > hackers. Other SpiderMonkey hackers should feel free to point out anything > else they see, that I might have missed. > > > > Jeff francis shields ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 couldn't increase to 99 > or 100? Viewability on-screen seems pretty weak in this era of > generally large screens. Printability's a better argument, but it's > unclear to me files are printed often enough for this to matter. I > do it one or two times a year, myself, these days. > > I don't think most JS hackers care for abuse of Hungarian notation > for scope-based (or const) naming. 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. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 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.) Jason People who use terminal-based editors for their coding are probably going to be rather likely to use the default window size for terminals: 80x24. Given that our style guide also requires adding vim and emacs modelines to files (aside: if we're talking about doing mass style-conversions, can we also fix modelines?), it seems reasonable that enough of our developers use vim and emacs to make force-resizing of terminal size defaults a noticeable cost. With 2-space indent, parsimonious indenting requirements (e.g., don't indent case: statements in switch or public in class), and liberal use of importing names into localized namespaces, the 80-column width isn't a big deal for most code. 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-contributor readability. Personally this doesn't bother me much (although "aCx" will always be painful compared to "cx" as two no-cap letters, I'm sure), but others are much more bothered. And a '_' at the end of member names requires less typing than 'm' + capital letter? My choice of when to use or not use Hungarian notation is often messy and seemingly inconsistent, although there is some method to my madness. 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. The use of 'a' for arguments is where I am least consistent, especially as I extremely dislike it being used for an outparam return value (disclaimer: I'm used to XPCOM-taminated code, so having to write NS_IMETHODIMP nsFoo::GetBoolValue(bool *retval) is common for me, and this colors my judgements a lot). I've never found much use for the 's', 'g', and 'k' prefixes, although that may just as well be because I've never found much use for using those types of variables in the first place (or when I do, it's because I'm being dictated by other concerns instead, e.g., type traits-like coding or C++11 polyfilling). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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-contributor readability. Personally this doesn't bother me much (although "aCx" will always be painful compared to "cx" as two no-cap letters, I'm sure), but others are much more bothered. Based on the discussion in #jsapi yesterday, I'm not sure that "most JS hackers" is necessarily accurate. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 not one of the SpiderMonkey hackers who strongly cares about prefixes or suffixes (although I think -Wshadow is worth using, somehow). So mFoo versus foo_ is not significantly different to me. But it does seem to me that mFoo *is* slightly more trouble than _ at end. _ at end doesn't affect any of the rest of the name. mFoo in contrast forces the first "real" letter to be capitalized, and often that's a floating capital in the middle of lowercase letters. When typing mFoo, the "F" is a precision-strike capital letter. Don't touch too early, don't touch too late, or you mistype. With "_" you can sometimes get away holding it slightly long because it doesn't "bleed" into the rest of the identifier. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 paragraph > >per line, boolean conditions must all be single line, and assume > >that people will deal, using an editor that handles such code > >usefully > > 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. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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, 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't increase to 99 or 100? Viewability on-screen seems pretty weak in this era of generally large screens. Printability's a better argument, but it's unclear to me files are printed often enough for this to matter. I do it one or two times a year, myself, these days. 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. People who use terminal-based editors for their coding are probably going to be rather likely to use the default window size for terminals: 80x24. Given that our style guide also requires adding vim and emacs modelines to files (aside: if we're talking about doing mass style-conversions, can we also fix modelines?), it seems reasonable that enough of our developers use vim and emacs to make force-resizing of terminal size defaults a noticeable cost. With 2-space indent, parsimonious indenting requirements (e.g., don't indent case: statements in switch or public in class), and liberal use of importing names into localized namespaces, the 80-column width isn't a big deal for most code. 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-contributor readability. Personally this doesn't bother me much (although "aCx" will always be painful compared to "cx" as two no-cap letters, I'm sure), but others are much more bothered. And a '_' at the end of member names requires less typing than 'm' + capital letter? My choice of when to use or not use Hungarian notation is often messy and seemingly inconsistent, although there is some method to my madness. 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. The use of 'a' for arguments is where I am least consistent, especially as I extremely dislike it being used for an outparam return value (disclaimer: I'm used to XPCOM-taminated code, so having to write NS_IMETHODIMP nsFoo::GetBoolValue(bool *retval) is common for me, and this colors my judgements a lot). I've never found much use for the 's', 'g', and 'k' prefixes, although that may just as well be because I've never found much use for using those types of variables in the first place (or when I do, it's because I'm being dictated by other concerns instead, e.g., type traits-like coding or C++11 polyfilling). -- Joshua Cranmer Thunderbird and DXR developer Source code archƦologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 >usefully 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 increased again. So I think that's a needless concern. One thing to mention: SM uses 4-space indents, and that makes the 99 char limit more of a win that it would be with 2-space indents. One annoying thing about SM is that *code* is allowed to be 99 chars, but comments are not supposed to exceed 80(!) This is kinda awful because you can't set up an editor (AFAIK) for both. I settled on setting my editor for 80 chars and then I manually unbreak longer lines (ugh). > On the flip side, I strongly dislike the JS style in which member > variables and constructor arguments frequently shadow each other. A trailing '_' (e.g. foo_) is sometimes used in SM for members. This helps reduce shadowing, but isn't sufficient, even if it's applied consistently. (I've beaten my head against this numerous times trying to enable -Wshadow, and failed every time.) I found the gFoo/sFoo/aFoo/mFoo style bizarre at first, but have come to prefer it. > I prefer non-bracing visually, but I've found the bracing to be > useful often enough when inserting debugging-printfs that I've come > to prefer it even though I think it's ugly and wastes space. It's pretty darn common to have a blank line after an indented block, in which case it doesn't end up wasting space. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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). 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't increase to 99 or 100? Viewability on-screen > seems pretty weak in this era of generally large screens. Printability's a > better argument, but it's unclear to me files are printed often enough for > this to matter. I do it one or two times a year, myself, these days. My argument against it is that there's a clear standard around 80ch since it's a longstanding terminal width, and if we start increasing the width, it'll keep increasing. People need to get an editor and terminal setup that works with the widest code they work with. However this works, it'll likely be able to deal with something a little bit wider than needed. Good enforcement of a defined standard does reduce the risk of creep due to this problem, but it doesn't reduce the chance that somebody will come along next year and ask for 120, etc. 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. I'm also concerned about what happens as we get older and have poorer vision. 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 usefully > 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-contributor readability. Personally this doesn't bother > me much (although "aCx" will always be painful compared to "cx" as two no-cap > letters, I'm sure), but others are much more bothered. On the flip side, I strongly dislike the JS style in which member variables and constructor arguments frequently shadow each other. I'm fine with switching here, as long as it's *to* something that doesn't yield this sort of shadowing. > JS people have long worked without bracing single-liners. With any style > guide's indentation requirements, they're a visually redundant waste of > space. Any style checker that checks both indentation and bracing (of course > we'll have one, right?), will warn twice for the error single-line bracing > prevents. I think most of us would discount the value of being able to add > more to a single-line block without changing the condition line. So I'm > pretty sure we're all dim on this one. I prefer non-bracing visually, but I've found the bracing to be useful often enough when inserting debugging-printfs that I've come to prefer it even though I think it's ugly and wastes space. -David -- š L. David Baron http://dbaron.org/ š š¢ Mozilla https://www.mozilla.org/ š Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 there in DOM code because we'd had too many instances of bugs being introduced due to the lack of braces -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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, 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't increase to 99 or 100? Viewability
on-screen seems pretty weak in this era of generally large screens.
Printability's a better argument, but it's unclear to me files are printed
often enough for this to matter. I do it one or two times a year, myself,
these days.
99 or 100 for line lengths sounds good to me. Use of templates has increased
quite significantly and 80ch isn't enough anymore.
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-contributor readability.
It is rather common to have prefixed variables names (outside Gecko), and it
increases readability of the code in many cases.
For example with out params it helps significantly when you know which thing is
actually the return value.
Also with long functions prefixes help to locate the variable definition.
Personally this
doesn't bother me much (although "aCx" will always be painful compared to "cx"
as two no-cap letters, I'm sure), but others are much more
bothered.
JS people have long worked without bracing single-liners. With any style
guide's indentation requirements, they're a visually redundant waste of
space. Any style checker that checks both indentation and bracing (of course
we'll have one, right?), will warn twice for the error single-line
bracing prevents. I think most of us would discount the value of being able to
add more to a single-line block without changing the condition
line. So I'm pretty sure we're all dim on this one.
I'd say consistency is good in this case. always {}. No special cases. And it
improves readability, since {} forces the almost-empty line
after the single-liner.
Skimming the rest of the current list, I don't see anything that would
obviously, definitely, be on the short list of complaints for SpiderMonkey
hackers. Other SpiderMonkey hackers should feel free to point out anything
else they see, that I might have missed.
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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 reason Mozilla couldn't increase to 99 or 100? Viewability > on-screen seems pretty weak in this era of generally large screens. > Printability's a better argument, but it's unclear to me files are printed > often enough for this to matter. I do it one or two times a year, myself, > these days. > I'm sympathetic and I don't recall any arguments against doing this. 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-contributor readability. Personally this > doesn't bother me much (although "aCx" will always be painful compared to > "cx" as two no-cap letters, I'm sure), but others are much more bothered. > I personally hate this style rule. I've argued against it vociferously. I lost. In the absence of a new killer argument against it, I'm resigned to living with it. If I can, you can too :-). JS people have long worked without bracing single-liners. With any style > guide's indentation requirements, they're a visually redundant waste of > space. Any style checker that checks both indentation and bracing (of > course we'll have one, right?), will warn twice for the error single-line > bracing prevents. I think most of us would discount the value of being > able to add more to a single-line block without changing the condition > line. So I'm pretty sure we're all dim on this one. > I actually prefer the bracing rule here. Ignoring that, it seems to me the downside of consistently bracing is small since I bet you often insert a blank line after the statement anyway. Thanks for bringing these up. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
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't increase to 99 or 100? btw, Firefox for Android's Java code uses a 100 character line length because Java identifier names are very verbose (and 100 characters is Google's coding style for its Android Java code). chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Mozilla style guide issues, from a JS point of view
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, it's a huge loss to revert to 80ch because of how much has to wrap. Is there a reason Mozilla couldn't increase to 99 or 100? Viewability on-screen seems pretty weak in this era of generally large screens. Printability's a better argument, but it's unclear to me files are printed often enough for this to matter. I do it one or two times a year, myself, these days. 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-contributor readability. Personally this doesn't bother me much (although "aCx" will always be painful compared to "cx" as two no-cap letters, I'm sure), but others are much more bothered. JS people have long worked without bracing single-liners. With any style guide's indentation requirements, they're a visually redundant waste of space. Any style checker that checks both indentation and bracing (of course we'll have one, right?), will warn twice for the error single-line bracing prevents. I think most of us would discount the value of being able to add more to a single-line block without changing the condition line. So I'm pretty sure we're all dim on this one. Skimming the rest of the current list, I don't see anything that would obviously, definitely, be on the short list of complaints for SpiderMonkey hackers. Other SpiderMonkey hackers should feel free to point out anything else they see, that I might have missed. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
