On 01/07/2014 01:11 AM, Joshua Cranmer wrote:
On 1/6/2014 6:06 PM, smaug wrote:
On 01/07/2014 01:38 AM, Joshua Cranmer wrote:
On 1/6/2014 4:27 PM, Robert O'Callahan wrote:
That's just not true, sorry. If some module owner decides to keep
using NULL or PRUnichar, or invent their own string
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
On Tuesday 2014-01-07 09:13 +0100, Ms2ger wrote:
On 01/07/2014 01:11 AM, Joshua Cranmer wrote:
Since Benjamin's message of November 22:
news://news.mozilla.org/mailman.11861.1385151580.23840.dev-platf...@lists.mozilla.org
(search for Please use NS_WARN_IF instead of NS_ENSURE_SUCCESS if you
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
Bobby Holley writes:
Note that there in a explicit stylistic exception that NS_WARN_IF
statements do not require braces. So it's:
if (NS_WARN_IF(NS_FAILED(rv)))
return rv;
I don't see that on the current version of
https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style
I
On https://bugzilla.mozilla.org/show_bug.cgi?id=641509 in the comments I can't
see any valid argument that backs up the decision to not fix the issue.
At least none that would stand to the objection which I posted as a comment:
Having a standard message always displayed is ok,
but what's the
On Tue, Jan 7, 2014 at 11:39 AM, matteosistise...@gmail.com wrote:
Can anybody explain not only to me but also to the number of people who
questioned the same, why the decision to not fix the issue is a good idea?
(despite by the way every other browser supporting that, except Opera which
On 01/07/2014 05:14 PM, smaug wrote:
On 01/07/2014 08:46 AM, Bobby Holley wrote:
On Mon, Jan 6, 2014 at 5:04 PM, smaug sm...@welho.com wrote:
no, since it is always possible to expand those macros.
However
if (NS_WARN_IF(NS_FAILED(rv)) {
return rv;
}
is super ugly.
Note that there in a
On 01/07/2014 08:46 AM, Bobby Holley wrote:
On Mon, Jan 6, 2014 at 5:04 PM, smaug sm...@welho.com wrote:
no, since it is always possible to expand those macros.
However
if (NS_WARN_IF(NS_FAILED(rv)) {
return rv;
}
is super ugly.
Note that there in a explicit stylistic exception that
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
On 1/6/2014, 8:05 PM, Karl Tomlinson wrote:
The bug is hidden almost as well by conversion of only indentation.
if (condition1)
if (condition2)
foo();
else
bar();
Sure, you could argue that style conversion makes the actual
behaviour clearer, but you'd have to know
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 1/6/2014, 8:05 PM, Karl Tomlinson wrote:
Gregory Szorc writes:
I think you just gave an example of why our tooling needs to
identify poorly formatted code better. An if without a brace
followed by multiple indented lines containing compiler
expressions is a bug at worst or
My point is that your arguments have been brought forward in the
discussion, and your post didn't bring anything new to the table. You might
disagree with the decision the contributors and owners of the affected
module have come to, and that's your right.
Snide remarks and shooting down
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 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.)
On 1/7/14 12:47 PM, Martin Thomson wrote:
I’ll just point out that this isn’t a bug if there are test cases that pass.
That depends on whether the test cases are correct (e.g. whether they
were written independently of the code, whether they were reviewed, etc)
-Boris
On Tue, Jan 7, 2014 at 9:38 AM, Adam Roach a...@mozilla.com 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
I filed bug 957201 for NS_WARN_IF_FAILED.
Andrew
- Original Message -
On 01/07/2014 02:58 AM, Karl Tomlinson wrote:
smaug sm...@welho.com writes:
Why this deprecation?
NS_ENSURE_ macros hid return paths.
Also many people didn't understand that they issued warnings, and
so
On Tuesday 2014-01-07 10:23 -0800, Bobby Holley wrote:
On Tue, Jan 7, 2014 at 9:38 AM, Adam Roach a...@mozilla.com 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
Hm. It's pretty unfortunate that we now need 4 lines per fallible call, as
opposed to 2 with NS_ENSURE_* macros. The stylistic exception made this 3,
which was slightly more palatable.
bholley
On Tue, Jan 7, 2014 at 7:26 AM, smaug sm...@welho.com wrote:
On 01/07/2014 05:14 PM, smaug wrote:
2014/1/7 L. David Baron dba...@dbaron.org
On Tuesday 2014-01-07 09:13 +0100, Ms2ger wrote:
On 01/07/2014 01:11 AM, Joshua Cranmer wrote:
Since Benjamin's message of November 22:
news://
news.mozilla.org/mailman.11861.1385151580.23840.dev-platf...@lists.mozilla.org
(search for Please
I support getting rid of NS_ENSURE_*.
Gavin
On Tue, Jan 7, 2014 at 3:13 AM, Ms2ger ms2...@gmail.com wrote:
On 01/07/2014 01:11 AM, Joshua Cranmer wrote:
On 1/6/2014 6:06 PM, smaug wrote:
On 01/07/2014 01:38 AM, Joshua Cranmer wrote:
On 1/6/2014 4:27 PM, Robert O'Callahan wrote:
Benoit Jacob wrote:
I would like a random voice in favor of deprecating NS_ENSURE_* for the reason
that hiding control flow behind macros is IMO one of the most evil usage
patterns of macros.
So you're saying that
nsresult rv = Foo();
NS_ENSURE_SUCCESS(rv, rv);
is hiding the control flow
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.
2014/1/7 Neil n...@parkwaycc.co.uk
Benoit Jacob wrote:
I would like a random voice in favor of deprecating NS_ENSURE_* for the
reason that hiding control flow behind macros is IMO one of the most evil
usage patterns of macros.
So you're saying that
nsresult rv = Foo();
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
On 2014-01-07, at 11:28, Benjamin Smedberg benja...@smedbergs.us 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
On 1/7/2014 12:58 PM, Benoit Jacob wrote:
I would like a random voice in favor of deprecating NS_ENSURE_* for
the reason that hiding control flow behind macros is IMO one of the
most evil usage patterns of macros.
In general, I would agree. I have no problems with killing, say,
On 1/6/2014 7:43 PM, smaug wrote:
Why this deprecation?
Karl is right, we are removing the macros that hide control flow (as
well as warnings, in this case).
I'm considering the NS_WARN_IF_FAILED(rv) proposal. It's obviously a
less typing then NS_WARN_IF(NS_FAILED(rv)), but I'm not
On 1/7/14 12:16, Martin Thomson wrote:
On 2014-01-06, at 19:28, Patrick McManus mcma...@ducksong.com 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
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:
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
On 1/5/2014 9:34 PM, Nicholas Nethercote wrote:
I propose that we officially remove this implicit discouragement, and even
encourage changes that convert non-Mozilla-style code to Mozilla-style (with
some exceptions; see below). When modifying badly-styled code, following
existing
There are a few C++-isms which vary widely across the tree and I'd like
to clarify before we start any major refactorings.
1) Bracing of method bodies in a C++ class declaration
Currently, C++ method bodies inline within a class declaration are
documented to start on the next line, e.g.
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
I agree that those are the current best practices.
We have a lot of places where we write void Method() { ... } all on one
line for trivial setters and getters. I wonder if we should permit that.
We have a lot of places where the opening brace of a class declaration is
on the same line as the
On Wed, Jan 8, 2014 at 9:46 AM, Mike Hoye mh...@mozilla.com 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
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
Sorry for the short notice.
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.
Meeting details:
* Tue, 7 January, 2:00 PM PST
*
On 1/7/2014, 2:29 PM, Martin Thomson wrote:
On 2014-01-07, at 11:28, Benjamin Smedberg benja...@smedbergs.us 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
I am happy to announce that the Valgrind test job is now visible on TBPL. The
abbreviation for the job is V, and it only runs on Linux64 opt
builds. Any failures
are cause for a patch to be backed out.
The job runs on try, and can be run locally (definitely on Linux, possibly on
Mac, not on
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
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 jpor...@mozilla.com wrote:
On 01/06/2014 08:23 PM, Karl Tomlinson wrote:
On Tue, Jan 7, 2014 at 11:28 AM, Benjamin Smedberg
benja...@smedbergs.us 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
On 1/7/2014, 4:55 PM, Chris Peterson wrote:
On 1/7/14, 12:31 PM, Benjamin Smedberg wrote:
What's not clear to me from the discussion is whether there is a
reformatting tool which already exists which can do what we need. If
there is, I think we should actively discourage people reformatting by
On 1/7/2014, 5:49 PM, Nicholas Nethercote wrote:
On Tue, Jan 7, 2014 at 11:28 AM, Benjamin Smedberg
benja...@smedbergs.us 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
On 1/7/2014, 3:53 PM, Robert O'Callahan wrote:
I agree that those are the current best practices.
We have a lot of places where we write void Method() { ... } all on one
line for trivial setters and getters. I wonder if we should permit that.
I'd rather if we didn't. Often times changing the
On 2014-01-07, at 14:52, Ehsan Akhgari ehsan.akhg...@gmail.com 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
Benjamin Smedberg wrote:
1) Bracing of method bodies in a C++ class declaration
Currently, C++ method bodies inline within a class declaration are
documented to start on the next line, e.g.
class B
{
public:
void Method()
{
// Inline body brace is on the next line, column 2
}
};
Mozilla code
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
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
On 1/7/2014, 6:18 PM, Cameron McCormack wrote:
Benjamin Smedberg wrote:
1) Bracing of method bodies in a C++ class declaration
Currently, C++ method bodies inline within a class declaration are
documented to start on the next line, e.g.
class B
{
public:
void Method()
{
// Inline body brace
Ehsan Akhgari wrote:
Exactly. If we require braces on their own lines for function bodies
everywhere, we wouldn't need to solve this!
Are you sure? :) There are a bunch of instances of
class A
{
A(int aMember)
: mMember(aMamber)
{}
};
through the tree. Depends how the
On Tue, Jan 7, 2014 at 12:31 PM, Benjamin Smedberg
benja...@smedbergs.us wrote:
I am the owner of at least the C/C++ portions of the style guide; I propose
to wait and see whether the C++ reformatting tools are of sufficient quality
that we can use them directly, to avoid hand-reformatting,
I tried to check in a reftest today. Apparently it fails on Android and
b2g. The failure mode appears to be that the reftest takes a screenshot
before the test has loaded (the page is still blank, whereas it should
have a red square for failure or a green square for success). Do
reftests
Benoit Jacob wrote:
I'm scanning a function for possible early returns
Good thing you don't have to deal with C++ exceptions then.
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On Tue, Jan 07, 2014 at 04:13:20PM -0800, Nicholas Nethercote wrote:
On Tue, Jan 7, 2014 at 12:31 PM, Benjamin Smedberg
benja...@smedbergs.us wrote:
I am the owner of at least the C/C++ portions of the style guide; I propose
to wait and see whether the C++ reformatting tools are of
FWIW, WebGL and GLContext do this for the same reasons.
-jgilbert
- Original Message -
From: Jeff Walden jwalden+...@mit.edu
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
On Tue, Jan 7, 2014 at 4:38 PM, Mike Hommey m...@glandium.org wrote:
So some hand-reformatting will be inevitable.
There are actually clang-based tools for e.g. variables renaming.
Thanks for the nit. I believe the broader point -- that tools won't
fix every style issue, so some
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
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 mozn...@karlt.net wrote:
L. David Baron
On Tue, Jan 7, 2014 at 11:29 AM, Benoit Jacob jacob.benoi...@gmail.comwrote:
For example, if I'm scanning a function for possible early returns (say I'm
debugging a bug where we're forgetting to close or delete a thing before
returning), I now need to scan for NS_ENSURE_SUCCESS in addition to
(2013/09/10 19:17), ishikawa wrote:
[ omissions ]
I am getting the hang of emacs mode line.
/* -*- Mode: javascript; tab-width: 8; indent-tabs-mode: nil;
c-basic-offset: 2 ; js-indent-level : 2 ; js-curly-indent-offset: 0 -*- */
/* vim: set ts=2 et sw=2 tw=80: */
seem to do the job.
On 14-01-07 08:04 PM, Kyle Huey wrote:
On Tue, Jan 7, 2014 at 11:29 AM, Benoit Jacob jacob.benoi...@gmail.comwrote:
For example, if I'm scanning a function for possible early returns (say I'm
debugging a bug where we're forgetting to close or delete a thing before
returning), I now need to
On Wed, Jan 08, 2014 at 10:23:28AM +0900, ISHIKAWA,chiaki wrote:
(2013/09/10 19:17), ishikawa wrote:
[ omissions ]
I am getting the hang of emacs mode line.
/* -*- Mode: javascript; tab-width: 8; indent-tabs-mode: nil;
c-basic-offset: 2 ; js-indent-level : 2 ;
On Tue, Jan 7, 2014 at 5:38 PM, Mike Hommey m...@glandium.org wrote:
Also, afaik, vim modelines are mostly useless, since
vim doesn't use them by default anyways
I enable them, and as long as we have some files with 2-space indents
and some with 4-space indents I will continue to find them
On 2014-01-07, at 17:38, Mike Hommey m...@glandium.org wrote:
Do we need so much boilerplate in all our files? With this and
vim-modeline, we now have editor boilerplate that takes as much space as
the MPL boilerplate. Also, afaik, vim modelines are mostly useless, since
vim doesn't use them
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:
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
On 1/7/14, 5:42 PM, Martin Thomson wrote:
Yeah, I thought that was the whole point of having a .emacs file. I’ve never
found those mode line things to be properly useful short of the point that it
includes the entire c-offsets-alist for the buffer. I’d rather the mode line
stuff be removed.
2014/1/7 Kyle Huey m...@kylehuey.com
On Tue, Jan 7, 2014 at 11:29 AM, Benoit Jacob jacob.benoi...@gmail.comwrote:
For example, if I'm scanning a function for possible early returns (say
I'm
debugging a bug where we're forgetting to close or delete a thing before
returning), I now need to
Chris Peterson writes:
If mozilla-central is reformatted, that would be a good time to
also remove the modelines.
5. Remove modelines from mozilla-central files
I'm happy with removal of modelines provided .dir-locals.el files
are added to provide the same functionality.
There is imported
I'd like to see the removal of the modelines also. A root config file is
much cleaner.
For the widest possible support of editors, I'd love to see a root
.editorconfig file. See http://editorconfig.org/ - it's an
editor-neutral config, with plugins for many editors/IDEs (including
Emacs,
74 matches
Mail list logo
