Should we have a common coding standard in Mozilla?
Mike Kristoffersen
original topic - this is one of these cases.
In the thread "Purpose of coding standard" a discussion has begun to
emerge that goes along the lines of a question as to whether or not we
want a common coding standard in Mozilla - or if we, as today should
allow for each module to have their own version of the coding standard.
I think that this discussion can run on its own, and it might be a good
example of where the values behind a coding standard becomes important
for what rules are found in the standard ;)
-----
As I understand it today, a default coding standard for C/C++ and IDL
exists today for at:
https://developer.mozilla.org/En/Developer_Guide/Coding_Style
A module owner/group leader can apparently decide to diverge from this
standard in any way that might fit personal preferences.
Now without going into specific exceptions/extensions is this what we
want in the future too - or will it be more beneficial to limit people
to a single cross-module coding standard?
The main argument I have heard for allowing modules to have their own
unique coding style is that Mozilla is about freedom and choice.
My counter argument to that is that we support open standards and work
against competitors inventing their own proprietary standards.
You could also start to argue why we accept different coding standards
at a module level, and not at file or class level.
But looking at a more down to earth argument, I believe it is easier for
everyone if we keep the same standard across modules. Its more easy
when you interact with different modules, or people trained in different
modules (like for reviews or when you need to do consequence changes in
other modules than your primary one).
Another argument is that if we allow standards to be... sorry for the
word, but dictated, by a single person or a small group of people then
there is a high risk that the next person coming to the position will
change that standard (because it haven't got the common acceptance of
being the best compromise in the community) - this in turn leads to the
standard fluctuating more over time than need be.
(And yes, I'm trying to change the standards now - but not dictate them
- I'm hoping through argumentation to be convinced that I'm wrong, or
convince others that I might have a point...)
^__^
Mike
Benjamin Smedberg
> As I understand it today, a default coding standard for C/C++ and IDL
> exists today for at:
> https://developer.mozilla.org/En/Developer_Guide/Coding_Style
>
> A module owner/group leader can apparently decide to diverge from this
> standard in any way that might fit personal preferences.
No they can't. There are certain decisions that modules differ on (preferred
indent, certain bracing rules, etc), but by and large the rules are pretty
uniform.
> The main argument I have heard for allowing modules to have their own
> unique coding style is that Mozilla is about freedom and choice.
>
> My counter argument to that is that we support open standards and work
> against competitors inventing their own proprietary standards.
Neither of these arguments has anything to do with our coding style.
What particular rules are you worried about changing between modules now?
--BDS
Mike Kristoffersen
> On 7/28/09 1:21 PM, Mike Kristoffersen wrote:
>
>
>> As I understand it today, a default coding standard for C/C++ and IDL
>> exists today for at:
>> https://developer.mozilla.org/En/Developer_Guide/Coding_Style
>>
>> A module owner/group leader can apparently decide to diverge from this
>> standard in any way that might fit personal preferences.
>
> No they can't. There are certain decisions that modules differ on (preferred
> indent, certain bracing rules, etc), but by and large the rules are pretty
> uniform.
Ok, to avoid further confusion - are you saying that a module owner can
define what indentation and branching rules they want in their module?
If that is the case can you give examples of what a module owner can't
change from the coding standard?
>
>> The main argument I have heard for allowing modules to have their own
>> unique coding style is that Mozilla is about freedom and choice.
>>
>> My counter argument to that is that we support open standards and work
>> against competitors inventing their own proprietary standards.
>
> Neither of these arguments has anything to do with our coding style.
These are not arguments to specific coding styles, these are arguments
for and against a specific module to have its own coding style rules -
like a special indentation rule. Both are taken from the "Purpose of a
coding standard" thread (and yes, the last one is mine).
>
> What particular rules are you worried about changing between modules now?
Any rule that differs between modules.
^__^
Mike
Benjamin Smedberg
> Benjamin Smedberg wrote:
>> On 7/28/09 1:21 PM, Mike Kristoffersen wrote:
>>
>>
>>> As I understand it today, a default coding standard for C/C++ and IDL
>>> exists today for at:
>>> https://developer.mozilla.org/En/Developer_Guide/Coding_Style
>>>
>>> A module owner/group leader can apparently decide to diverge from this
>>> standard in any way that might fit personal preferences.
>> No they can't. There are certain decisions that modules differ on (preferred
>> indent, certain bracing rules, etc), but by and large the rules are pretty
>> uniform.
>
> Ok, to avoid further confusion - are you saying that a module owner can
> define what indentation and branching rules they want in their module?
The owner can request 2 or 4-space indentation, especially to match existing
practice in the module. The owner can also request that single-line if
blocks have braces or no braces, e.g.
if (foo) {
bar;
}
OR
if (foo)
bar;
> If that is the case can you give examples of what a module owner can't
> change from the coding standard?
* Tabs are not allowed.
* The C++ portability rules
* method && member naming conventions
* most of the other rules...
>>> The main argument I have heard for allowing modules to have their own
>>> unique coding style is that Mozilla is about freedom and choice.
>>>
>>> My counter argument to that is that we support open standards and work
>>> against competitors inventing their own proprietary standards.
>> Neither of these arguments has anything to do with our coding style.
>
> These are not arguments to specific coding styles, these are arguments
> for and against a specific module to have its own coding style rules -
> like a special indentation rule. Both are taken from the "Purpose of a
> coding standard" thread (and yes, the last one is mine).
"freedom and choice" is not incompatible with a unified code style, and open
standards have nothing to do with how we format our code, since there is not
a C++ code formatting standards body that we're conforming to as an
organization. Both arguments are irrelevant nonsense.
--BDS
Mike Kristoffersen
> The owner can request 2 or 4-space indentation, especially to match existing
> practice in the module. The owner can also request that single-line if
> blocks have braces or no braces, e.g.
I can understand (and partly support) that you should follow the overall
style that exist in a given source file - but I'm yet to hear an
argument that this should be done on a module level (like 2 or 4 tabs).
What is the argument that we should allow special rules on a module level?
>> If that is the case can you give examples of what a module owner can't
>> change from the coding standard?
>
> * Tabs are not allowed.
> * The C++ portability rules
> * method && member naming conventions
> * most of the other rules...
As I hopefully have made clear, I'm in favor of having the same rules in
all modules, but lets say the general community are in favor of a
certain degree of freedom to some of the rules (on a module or file
level) would it then be an idea to stress this in the coding standard?
I mean like stating: "The tab size must be 2 in modules x,y and z and 4
in modules a, b and c."
And for the rules we want to enforce cross modules: "Tabs are not
allowed in any modules" - or maybe as a generic statement in the
beginning of the standard, stating that "All rules must be followed in
all modules, except otherwise explicitly stated in the individual rules"
>
> "freedom and choice" is not incompatible with a unified code style, and open
> standards have nothing to do with how we format our code, since there is not
> a C++ code formatting standards body that we're conforming to as an
> organization. Both arguments are irrelevant nonsense.
I'm not to judge if an argument someone else comes with is relevant or
not, I'm sure who ever gives an argument thinks it is relevant in the
discussion :) However I might try to find a more relevant argument as a
response, or silently ignore it if it is beyond my understanding ;)
^__^
Mike
Robert Strong
> Benjamin Smedberg wrote:
>
>> The owner can request 2 or 4-space indentation, especially to match existing
>> practice in the module. The owner can also request that single-line if
>> blocks have braces or no braces, e.g.
>>
> I can understand (and partly support) that you should follow the overall
> style that exist in a given source file - but I'm yet to hear an
> argument that this should be done on a module level (like 2 or 4 tabs).
>
> What is the argument that we should allow special rules on a module level?
>
see any value in not allowing this to be module or even file specific.
For example, what actual value is there in requiring all modules to
adhere to a 2 space rule?
>>> If that is the case can you give examples of what a module owner can't
>>> change from the coding standard?
>>>
>> * Tabs are not allowed.
>> * The C++ portability rules
>> * method&& member naming conventions
>> * most of the other rules...
>>
> As I hopefully have made clear, I'm in favor of having the same rules in
> all modules, but lets say the general community are in favor of a
> certain degree of freedom to some of the rules (on a module or file
> level) would it then be an idea to stress this in the coding standard?
>
> I mean like stating: "The tab size must be 2 in modules x,y and z and 4
> in modules a, b and c."
>
This is currently enforced by the rule to follow the file's prevailing
style.
> And for the rules we want to enforce cross modules: "Tabs are not
> allowed in any modules" - or maybe as a generic statement in the
> beginning of the standard, stating that "All rules must be followed in
> all modules, except otherwise explicitly stated in the individual rules"
>
Rules that are to be enforced across modules are typically enforced by
the reviewer.
>> "freedom and choice" is not incompatible with a unified code style, and open
>> standards have nothing to do with how we format our code, since there is not
>> a C++ code formatting standards body that we're conforming to as an
>> organization. Both arguments are irrelevant nonsense.
>>
> I'm not to judge if an argument someone else comes with is relevant or
> not, I'm sure who ever gives an argument thinks it is relevant in the
> discussion :) However I might try to find a more relevant argument as a
> response, or silently ignore it if it is beyond my understanding ;)
>
In reading this thread I was thinking along the same lines as Benjamin
stated and was hoping for the rationale / justification behind the
argument vs. just stating it is so. What specifically isn't working now
that needs to be fixed and specifically how this approach to coding
standards would fix this as it relates to the current method?
Cheers,
Robert
Benjamin Smedberg
> Benjamin Smedberg wrote:
>> The owner can request 2 or 4-space indentation, especially to match existing
>> practice in the module. The owner can also request that single-line if
>> blocks have braces or no braces, e.g.
>
> I can understand (and partly support) that you should follow the overall
> style that exist in a given source file - but I'm yet to hear an
> argument that this should be done on a module level (like 2 or 4 tabs).
>
> What is the argument that we should allow special rules on a module level?
What's the argument that we shouldn't?
I can think up several potential arguments
* it's harder to configure IDEs
* it's hard to copy/paste code between modules
On the other hand, we have a mix of 2 and 4-space indents right now... we're
basically describing the way things are, and keeping consistency within a
module is important.
If you're arguing that we should trade off differently, please just make
your case instead of beating around the bush.
> I mean like stating: "The tab size must be 2 in modules x,y and z and 4
> in modules a, b and c."
Which one of the following is more complicated for a user:
A. check the style guide. It says to look at the surrounding code and use
the same pattern for new code. You look around, see 4-space indents and use
that.
B. check the style guide. It gives a list of modules which behave in certain
ways. Then you have to figure out which module your code is in.
option A is more effective in practice
> And for the rules we want to enforce cross modules: "Tabs are not
> allowed in any modules" - or maybe as a generic statement in the
> beginning of the standard, stating that "All rules must be followed in
> all modules, except otherwise explicitly stated in the individual rules"
You would have great precision in this document, at the cost of making it
easy to read and understand.
If you don't think the current system of reviewers enforcing code style is
working well, please be specific about how it's not working and how you
think we could make it better. So far this meta-discussion has not had a
good problem statement.
--BDS
Joshua Cranmer
> I can understand (and partly support) that you should follow the overall
> style that exist in a given source file - but I'm yet to hear an
> argument that this should be done on a module level (like 2 or 4 tabs).
>
> What is the argument that we should allow special rules on a module level?
Because working with a file that mixes five different coding styles is
no fun and touching half the lines in the file just to unify everything
into a single standard is annoying in terms of history.
> And for the rules we want to enforce cross modules: "Tabs are not
> allowed in any modules" - or maybe as a generic statement in the
> beginning of the standard, stating that "All rules must be followed in
> all modules, except otherwise explicitly stated in the individual rules"
The only rules that I know of that vary are the basic whitespace rules:
line width (80, 100, infinity), indent width (2 and 4 are the common
ones), and brace style (on newline or not). I've also seen some
differences in the indentation of multi-line statements (where does the
second line on if or method calls start?).
Mike Kristoffersen
Gijs Kruitbosch writes:
>> If we assume any given rule/recommendation in the
>> standard(s) are there for a reason - I don't see why in general these
>> reasons should be different for different modules.
>
> There are rules/recommendations upon which everyone agrees (eg. don't
> write bazillion-character lines of code unless there is no way of
> avoiding this) and specifics (eg. the exact definition of "bazillion"
> and/or the specific requirements for the "unless" clause to apply) about
> which people do not agree. I am not sure it is beneficial to specify the
> former (as it's not specific enough to be useful) nor the latter (as
> it'll annoy people over things not worth annoying them about) any more
> than they are - without seeing specific examples of where you think our
> standards don't do a good enough job. :-)
Hmmm... I hope you are not saying, we must keep module owners happy if
we can? - hmm... that came out in the wrong way, I don't want to annoy
module owners, but taking your example of line lengths (I assume that is
what you are talking about), it doesn't improve anything to have
different rules in different modules, while a given person might have
his preference at the width of his favorite text editor, it does not in
general improve readability, or maintainability, to have different rules
in different modules - it does however raise the learning curve for each
module and can be a source of reduced readability and/or an increased
number of review cycles if you get it wrong in a module.
As a minimum I believe it should be explicitly stated in the coding
standard if there are differences between modules - it might be that
exposing the differences in this way will slowly ensure they diverge in
the same direction until they can be replaced by a single rule that
covers all modules.
^__^
Mike
Mike Kristoffersen
> On 7/28/2009 1:28 PM, Mike Kristoffersen wrote:
>> Benjamin Smedberg wrote:
>>
>>> The owner can request 2 or 4-space indentation, especially to match
>>> existing
>>> practice in the module. The owner can also request that single-line if
>>> blocks have braces or no braces, e.g.
>>>
>> I can understand (and partly support) that you should follow the overall
>> style that exist in a given source file - but I'm yet to hear an
>> argument that this should be done on a module level (like 2 or 4 tabs).
>>
>> What is the argument that we should allow special rules on a module
>> level?
>>
> In relation to 2 or 4 space and many other rules / guidelines I don't
> see any value in not allowing this to be module or even file specific.
> For example, what actual value is there in requiring all modules to
> adhere to a 2 space rule?
If we look at whether we should use 2 or 4 spaces for indentation in
general, the argument for 2 spaces over 4 is that two spaces allow more
nested indentation before you get into trouble with the right margin -
this must be as true for one module as it is for another module. Hence
it is in general better to have 2 space indentation than 4.
The counter argument is that 4 spaces makes it more easy to line up the
beginning and end of deeply nested indentations.
That means when choosing between the two we have to make up our mind
which one we want give more weight - it is the same question we must ask
for every module/file, and I don't see how the same question can give
different answers just because the indentation happens in different files.
I'm personally in favor of a 2 space indentation, but that is beyond the
purpose of the discussion in this thread.
>> As I hopefully have made clear, I'm in favor of having the same rules in
>> all modules, but lets say the general community are in favor of a
>> certain degree of freedom to some of the rules (on a module or file
>> level) would it then be an idea to stress this in the coding standard?
>>
>> I mean like stating: "The tab size must be 2 in modules x,y and z and 4
>> in modules a, b and c."
>>
> This is currently enforced by the rule to follow the file's prevailing
> style.
But it does not cover the case of new files.
>
>> And for the rules we want to enforce cross modules: "Tabs are not
>> allowed in any modules" - or maybe as a generic statement in the
>> beginning of the standard, stating that "All rules must be followed in
>> all modules, except otherwise explicitly stated in the individual rules"
>>
> Rules that are to be enforced across modules are typically enforced by
> the reviewer.
Yes, the idea of reviews are amongst other things to catch mistakes
where the coding standard isn't being followed, the rules can't be
rules, in my opinion, if they have not been discussed and written down,
which is why we have a coding standard in the first place or ???
>>> "freedom and choice" is not incompatible with a unified code style,
>>> and open
>>> standards have nothing to do with how we format our code, since there
>>> is not
>>> a C++ code formatting standards body that we're conforming to as an
>>> organization. Both arguments are irrelevant nonsense.
>>>
>> I'm not to judge if an argument someone else comes with is relevant or
>> not, I'm sure who ever gives an argument thinks it is relevant in the
>> discussion :) However I might try to find a more relevant argument as a
>> response, or silently ignore it if it is beyond my understanding ;)
>>
> In reading this thread I was thinking along the same lines as Benjamin
> stated and was hoping for the rationale / justification behind the
> argument vs. just stating it is so. What specifically isn't working now
> that needs to be fixed and specifically how this approach to coding
> standards would fix this as it relates to the current method?
I didn't come with the "freedom of choice" argument in the first place
(even I might have rephrased it), my response about web-standards was in
my opinion an argument on the same level of abstraction :)
^__^
Mike
Robert Strong
simple and that enforcing a 2 or 4 space indentation is not something
that provides any significant value. This is moot atm as I see it per my
reply below.
>>> As I hopefully have made clear, I'm in favor of having the same rules in
>>> all modules, but lets say the general community are in favor of a
>>> certain degree of freedom to some of the rules (on a module or file
>>> level) would it then be an idea to stress this in the coding standard?
>>>
>>> I mean like stating: "The tab size must be 2 in modules x,y and z and 4
>>> in modules a, b and c."
>>>
>>>
>> This is currently enforced by the rule to follow the file's prevailing
>> style.
>>
> But it does not cover the case of new files.
>
New files typically follow the same style rules of the module or parent.
This is moot atm as I see it per my reply below.
>>> And for the rules we want to enforce cross modules: "Tabs are not
>>> allowed in any modules" - or maybe as a generic statement in the
>>> beginning of the standard, stating that "All rules must be followed in
>>> all modules, except otherwise explicitly stated in the individual rules"
>>>
>>>
>> Rules that are to be enforced across modules are typically enforced by
>> the reviewer.
>>
> Yes, the idea of reviews are amongst other things to catch mistakes
> where the coding standard isn't being followed, the rules can't be
> rules, in my opinion, if they have not been discussed and written down,
> which is why we have a coding standard in the first place or ???
>
There is nothing that says rules have to be written down and they can
still be enforced by review / verbally / etc. There is nothing wrong
with documenting the rules that are not documented as there is nothing
wrong with rules in general but I don't believe that rules should be
added that don't provide value. This is my main concern with what you
have proposed since IMO you haven't provided a good problem statement as
Benjamin stated previously.
>>>> "freedom and choice" is not incompatible with a unified code style,
>>>> and open
>>>> standards have nothing to do with how we format our code, since there
>>>> is not
>>>> a C++ code formatting standards body that we're conforming to as an
>>>> organization. Both arguments are irrelevant nonsense.
>>>>
>>>>
>>> I'm not to judge if an argument someone else comes with is relevant or
>>> not, I'm sure who ever gives an argument thinks it is relevant in the
>>> discussion :) However I might try to find a more relevant argument as a
>>> response, or silently ignore it if it is beyond my understanding ;)
>>>
>>>
>> In reading this thread I was thinking along the same lines as Benjamin
>> stated and was hoping for the rationale / justification behind the
>> argument vs. just stating it is so. What specifically isn't working now
>> that needs to be fixed and specifically how this approach to coding
>> standards would fix this as it relates to the current method?
>>
> I didn't come with the "freedom of choice" argument in the first place
> (even I might have rephrased it), my response about web-standards was in
> my opinion an argument on the same level of abstraction :)
>
My question wasn't specifically in regards to the "freedom of choice"
argument and I would still like a reply to my question.
> In reading this thread I was thinking along the same lines as Benjamin
> stated and was hoping for the rationale / justification behind the
> argument vs. just stating it is so. What specifically isn't working now
> that needs to be fixed and specifically how this approach to coding
> standards would fix this as it relates to the current method?
So, what is the specific problem you are trying to solve and how does
your suggestion solve this problem in comparison to the current method?
I'm quite willing to believe there is a problem to solve but all other
discussion is moot until the root problem is well defined / understood
as I see it.
Robert
Mike Kristoffersen
> On 7/28/09 4:28 PM, Mike Kristoffersen wrote:
>> Benjamin Smedberg wrote:
>>> The owner can request 2 or 4-space indentation, especially to match existing
>>> practice in the module. The owner can also request that single-line if
>>> blocks have braces or no braces, e.g.
>> I can understand (and partly support) that you should follow the overall
>> style that exist in a given source file - but I'm yet to hear an
>> argument that this should be done on a module level (like 2 or 4 tabs).
>>
>> What is the argument that we should allow special rules on a module level?
>
> What's the argument that we shouldn't?
>
> I can think up several potential arguments
> * it's harder to configure IDEs
> * it's hard to copy/paste code between modules
>
> On the other hand, we have a mix of 2 and 4-space indents right now... we're
> basically describing the way things are, and keeping consistency within a
> module is important.
>
> If you're arguing that we should trade off differently, please just make
> your case instead of beating around the bush.
I'm I understanding you correctly in that in principle you are in favor
of having the same standard in all modules? - The reason not to have it
is simply to keep consistency within a module? (btw. nice reasons for
keeping the same standard, I didn't think of these)
If the above is not what you mean, then ignore the next few paragraphs :)
But if the above is what you believe, then there is no reason for me to
preach for common standards across modules to you with my argumentation
- because then it is no longer a choice made by the module owner, then
the module owner is forced to the choice by historical reasons.
I'm sorry I didn't get your point initially.
In light of this dilemma being the main cause, my argumentation goes to
this:
We can either choose to keep things like it is, with the problems it
gives us, which on the long term is only a small step in the general
degeneration (is that the right word?) of code over time.
Or we can choose a road that on the medium term will solve this problem
at a cost now, but a gain on the long run. That means we must have a
plan for aligning all the code to the same standard - the best way to do
this depends on the specific changes that are needed - for things like
indentation, placement of '{', '}', line lengths and the use of spaces
we can say that any new code, or functions(!) that are being changed for
other reasons should be formatted to the common rules. So over time the
files that are being edited will adhere to the new rules. Files that
are not being edited on a regular basis can be changed in cleanup
sessions, or left alone.
>
>> I mean like stating: "The tab size must be 2 in modules x,y and z and 4
>> in modules a, b and c."
>
> Which one of the following is more complicated for a user:
>
> A. check the style guide. It says to look at the surrounding code and use
> the same pattern for new code. You look around, see 4-space indents and use
> that.
> B. check the style guide. It gives a list of modules which behave in certain
> ways. Then you have to figure out which module your code is in.
>
> option A is more effective in practice
We get into trouble by using A if the current code mixes styles - and it
gives us a dilemma for new files.
>> And for the rules we want to enforce cross modules: "Tabs are not
>> allowed in any modules" - or maybe as a generic statement in the
>> beginning of the standard, stating that "All rules must be followed in
>> all modules, except otherwise explicitly stated in the individual rules"
>
> You would have great precision in this document, at the cost of making it
> easy to read and understand.
The document is not worth much in my view, if it doesn't describe the
rules...
> If you don't think the current system of reviewers enforcing code style is
> working well, please be specific about how it's not working and how you
> think we could make it better. So far this meta-discussion has not had a
> good problem statement.
ok :) - I think it is very important to have reviewers catch glitches in
coding styles, I'm in no way opposed to the review process - I think we
can automate some of it, but I'm not against the idea of reviews!
However I have a problem with reviewers pointing out coding style issues
that aren't described in the coding standard - I have both personal
experience with, and have seen others comment in the news groups that a
reviewer has stated something like: We tend to do something in a given
way, or we are working towards doing something in a given way.
Sometimes even prefixed with something like, "in this module".
It is my strong opinion that if we want to move the coding style in a
certain direction then that should be stated clearly (after a proper
discussion) on a web-page known by all.
This is my overall goal with the discussions I'm trying to have here - I
actually started out with questioning a few of the rules in the coding
standard - but analyzing them more deeply (like where to put pairs of
'{' and '}') I came to the conclusion that it really depended on what we
wanted to put emphasis on in our code - hence I felt the need for a more
general discussion on the purpose of the coding standard... :)
^__^
Mike
Mike Kristoffersen
> There is nothing that says rules have to be written down and they can
> still be enforced by review / verbally / etc. There is nothing wrong
> with documenting the rules that are not documented as there is nothing
> wrong with rules in general but I don't believe that rules should be
> added that don't provide value. This is my main concern with what you
> have proposed since IMO you haven't provided a good problem statement as
> Benjamin stated previously.
I think there is a big problem with not writing down the rules for a
project like the one we work on, where people join at random, and where
the majority probably don't have time to follow all discussions -
implicit rules, or rules that aren't documented work great in a small
group of people, but this project is not for a small group of people.
In my opinion it's a waste of the reviewers time, if the reviewer has to
explain the rules to every new contributer, rather than just writing
them down one time and pointing to that for further reference.
I totally agree that there is no reason to have rules that don't provide
any real value! - but a rule doesn't provide more value, because it
isn't written down :) - enforcing rules to be written down, might even
make us think twice about setting requirements for doing things in a
specific way. Hence avoiding some of the rules that don't really add
any value. Like what real value does it add to avoid white spaces at
line ends?
>>> In reading this thread I was thinking along the same lines as Benjamin
>>> stated and was hoping for the rationale / justification behind the
>>> argument vs. just stating it is so. What specifically isn't working now
>>> that needs to be fixed and specifically how this approach to coding
>>> standards would fix this as it relates to the current method?
>>>
>> I didn't come with the "freedom of choice" argument in the first place
>> (even I might have rephrased it), my response about web-standards was in
>> my opinion an argument on the same level of abstraction :)
>>
> My question wasn't specifically in regards to the "freedom of choice"
> argument and I would still like a reply to my question.
I hope your question has been answered above, and in my last reply to
Benjamin? - If you want me to elaborate, plz ask again :)
>
>> In reading this thread I was thinking along the same lines as Benjamin
>> stated and was hoping for the rationale / justification behind the
>> argument vs. just stating it is so. What specifically isn't working now
>> that needs to be fixed and specifically how this approach to coding
>> standards would fix this as it relates to the current method?
>
> So, what is the specific problem you are trying to solve and how does
> your suggestion solve this problem in comparison to the current method?
> I'm quite willing to believe there is a problem to solve but all other
> discussion is moot until the root problem is well defined / understood
> as I see it.
With this thread my goal is to have a common cross-module coding
standard, and if I can't have that, then to have a documented coding
standard.
I'm well aware that I might have neither at this time, as you are tough
guys to discuss with, but I'm sure gonna try, and I'll keep doing that
as long as I believe I have a case :)
^__^
Mike
Robert O'Callahan
> On 7/28/09 4:28 PM, Mike Kristoffersen wrote:
>> What is the argument that we should allow special rules on a module level?
>
> What's the argument that we shouldn't?
>
> I can think up several potential arguments
> * it's harder to configure IDEs
> * it's hard to copy/paste code between modules
* it's hard to make changes that cut across modules while following the
correct prevailing style in each module. Actually it's impossible, and
for reviewers too. This leads to in-module style consistency being lost,
so you end up with no style consistency at all. Example: focus manager.
I don't blame Neil or Olli or anyone else; getting the styles all right
for a patch like that is just too difficult.
I posted about this in .dev.platform recently, FWIW.
> Which one of the following is more complicated for a user:
>
> A. check the style guide. It says to look at the surrounding code and use
> the same pattern for new code. You look around, see 4-space indents and use
> that.
> B. check the style guide. It gives a list of modules which behave in certain
> ways. Then you have to figure out which module your code is in.
>
> option A is more effective in practice
How about
C. check the style guide. It tells you to use 4 spaces.
Rob
Mike Kristoffersen
> Mike Kristoffersen wrote:
>> I can understand (and partly support) that you should follow the overall
>> style that exist in a given source file - but I'm yet to hear an
>> argument that this should be done on a module level (like 2 or 4 tabs).
>>
>> What is the argument that we should allow special rules on a module
>> level?
>
> Because working with a file that mixes five different coding styles is
> no fun and touching half the lines in the file just to unify everything
> into a single standard is annoying in terms of history.
I'm finding it less than optimal that I need to use one coding standard
in one file, and another in another file :)
Whether or not it hurts the history of the file, really depends on what
element in the coding standard that is being changed, going from an 80
char line length to a 100 don't need to hurt the history, nor relaxing
any rules that are enforced (like the module that didn't allow the use
of CC/Ci/Cr/Cu that was mentioned in the "Purpose of coding standard"
thread. btw. i have no idea what CC/Ci/Cr/Cu is...)
>> And for the rules we want to enforce cross modules: "Tabs are not
>> allowed in any modules" - or maybe as a generic statement in the
>> beginning of the standard, stating that "All rules must be followed in
>> all modules, except otherwise explicitly stated in the individual rules"
>
> The only rules that I know of that vary are the basic whitespace rules:
> line width (80, 100, infinity), indent width (2 and 4 are the common
> ones), and brace style (on newline or not). I've also seen some
> differences in the indentation of multi-line statements (where does the
> second line on if or method calls start?).
One could read what you write as, there are some standards that are so
insignificant that they don't need to be documented :) I'm sure you
have another point?
^__^
Mike
Mike Kristoffersen
> On 29/7/09 8:58 AM, Benjamin Smedberg wrote:
>> On 7/28/09 4:28 PM, Mike Kristoffersen wrote:
>>> What is the argument that we should allow special rules on a module
>>> level?
>>
>> What's the argument that we shouldn't?
>>
>> I can think up several potential arguments
>> * it's harder to configure IDEs
>> * it's hard to copy/paste code between modules
>
> * it's hard to make changes that cut across modules while following the
> correct prevailing style in each module. Actually it's impossible, and
> for reviewers too. This leads to in-module style consistency being lost,
> so you end up with no style consistency at all. Example: focus manager.
> I don't blame Neil or Olli or anyone else; getting the styles all right
> for a patch like that is just too difficult.
1) If we agree on a common style, the prevailing style in a module might
not be correct
2) It will be easier for everyone if the rules are the same in all modules
3) Whether or not the in-module consistency is important or not, depends
on what the inconsistency is! - for a thing like naming conventions,
yes, it might be less than optimal, but again it depends on what the
change is (but no-one has mentioned different rules for naming
conventions in this thread), for the tab-with, I don't think it is
significant (on a module level, if we are in a process of transferring
from one standard to another one - and a good diff tool will btw ignore
differences in white spaces)
>
> I posted about this in .dev.platform recently, FWIW.
>
>> Which one of the following is more complicated for a user:
>>
>> A. check the style guide. It says to look at the surrounding code and use
>> the same pattern for new code. You look around, see 4-space indents
>> and use
>> that.
>> B. check the style guide. It gives a list of modules which behave in
>> certain
>> ways. Then you have to figure out which module your code is in.
>>
>> option A is more effective in practice
>
> How about
> C. check the style guide. It tells you to use 4 spaces.
:) It might be 4 is better than 2 - looking forward to have that
discussion with you... - but your point that there should only be one
standard is exactly what I'm arguing for ;) -hope I'm not insulting you
by saying that :)
^__^
Mike
Robert Kaiser
> Now without going into specific exceptions/extensions is this what we
> want in the future too - or will it be more beneficial to limit people
> to a single cross-module coding standard?
I think we should have to have modularized rules under the diction of
module owners with some form of common *guidelines* (not strict rules!).
And we have super-review for making modules play well together and be as
consistent as useful, decided on a case-by-case basis.
And, basically, this is just what we have and what has proven to work
successfully over the last couple of years.
Robert Kaiser
Joshua Cranmer
> How about
> C. check the style guide. It tells you to use 4 spaces.
And I quote:
Files should have an Emacs mode line comment as the first line of the
file, which should set indent-tabs-mode to nil. For new files, use this,
specifying 2-space indentation:
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2
-*- */
That's the only mention of indentation (not even in the formatting
guide), which implies that 2 is the correct indentation in the style
guide. I apologize for the bikeshedding responses in advance.
Mike Kristoffersen
What I hear you say, is that there is no reasons to change it, because
the current system is working. I would make the brave claim, that it
would probably also work without rules for indentation or placement of
brackets.
Yes, we have a system where it is possible for multiple people to
contribute and develop great software - and more importantly I think we
can make the system better and more easy for new people to join and
maintain than it is now :)
^__^
Mike
L. David Baron
> Yes, we have a system where it is possible for multiple people to
> contribute and develop great software - and more importantly I think we
> can make the system better and more easy for new people to join and
> maintain than it is now :)
I'd rather have contributors who start out by fixing code that's
causing problems for them, and might need to be told that it doesn't
match local style perfectly, but are alert enough to recognize if
it's obviously different from the code two lines earlier. I don't
care about the needs of potential contributors who aren't going to
type anything until they've researched whether their bracing style
is correct, because I don't think they'll become useful contributors
to a complex software project.
Things like coding style guidelines aren't for people writing their
first patches; they're for people who have already contributed a
bunch of patches and want to learn more about why things are the way
they are in order to take on greater responsibility.
-David
[1] http://en.wikipedia.org/wiki/Wikipedia:BB
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Robert O'Callahan
I don't care whether the number is 2, 4 or 7, as long as it's consistent
across modules.
Robert O'Callahan
> And, basically, this is just what we have and what has proven to work
> successfully over the last couple of years.
It is not working successfully. I point to large cross-cutting patches
that are corrupting module-specific styles as evidence that our current
approach inevitably leads to loss of all style consistency over time.
Rob
Stuart Parmenter
contributors coming in to the project requiring them to learn quite a
few different styles. I've been working on Mozilla forever, and I've
almost given up on several JS patches when all the review comments
came back as style changes. I would really like to see us discuss
this further and productively, and lets see if we can come up with a
style guide that can work across modules. I'm not going to suggest we
move to it immediately, but certainly would suggest that new code
follow it and that we look at using some analysis tools to change some
of these things automatically for us.
stuart
Blake Kaplan
> We're quite inconsistent throughout our code, and I think it hurts new
> contributors coming in to the project requiring them to learn quite a
> few different styles.
> I've been working on Mozilla forever, and I've
> almost given up on several JS patches when all the review comments
These two ideas are contradictory. The only way to maintain a consistent style
(even if only in one module) is to be very strict about it. Otherwise you end
up with what we have in the rest of Mozilla, which is a hodgepodge of
different styles. Maybe eventually, the answer will be better tools, but for
now modules that care deeply about this stuff (which, as you noted, really
does help new contributors) will simply need to bounce patches based on style
rules.
--
Blake Kaplan
Brendan Eich
+∞
Also +∞ for dbaron's post.
Roc, why did the cross-cutting patch not match local style? Did the
patch author ignore it (too busy, too important cross-cutting work,
what)? How about reviewers?
I think the problem here is overstated. Any large-enough project will
have some style inconsistency or (better, as descriptive phrase and
normative good) style *subsidiarity*. Is your house the same as your
neighbors' houses, even if in the same tract? Some important stuff may
be consistent (power outlet spacing, truss design and load limits,
etc. etc.) but that is substance not style.
Now, if I invite you into my house to help remodel the kitchen in
stylistic (only; or as well as substantial) ways, and my house is neo-
Victorian, and you start adding your favorite Bauhaus-minimalist style
cabinets, there will be trouble!
If you are a cross-cutting house-patcher (presumably you're from the
government and you are here to help :-/), I'll still want to have my
say, or it's not my house.
Is a module less analogous to a house and more like a public space
that has to follow a common style? Anyone who has seen some US public
spaces blighted by bad architecture theory may join me in demurring.
But "module" connotes boundary between the inside that is not
outsider's business, and the outside (public APIs and observable
behavior). This meaning is important even if one does hack cross-
module occasionally.
The meaning of "module" is based on human limitations in containing
complexity, and also (I argue) on social limits on "style control".
Different societies have different limits, for sure (consider the
Puritans! ;-). But in my experience, Mozilla's limits severely
constrain the amount of internal stylistic consistency we should try
to require.
In the past (Mork, ahem) we have tolerated really bizarre style,
"outlier style", in some contributed code. We shouldn't want such
intentionally abnormal style code. But with contributors who add
value, and with module boundaries defined by solid APIs, how much
uniformity should we expect? How much should we want?
No tabs helps people read what other people write with a certain
indentation/layout in mind. Modern tools support auto-expanding, so
this is not a hardship.
Brace style is a matter more or risk exposure vs. tolerance (dangling
else), and pure aesthetics. I don't want to legislate too much, and I
bet if I did, the law would be an ass (not followed).
Mainly, I want to see consistent style in other modules than those I
own, but not necessarily *my* style, or a *common* (as in least common
denominator) style.
I hope this helps, but I suspect if we're ratholing on this topic,
then something else is wrong. What might that "something else" be?
/be
Robert O'Callahan
> Roc, why did the cross-cutting patch not match local style? Did the
> patch author ignore it (too busy, too important cross-cutting work,
> what)? How about reviewers?
When you've got a patch that touches N different modules, changing a few
lines in each one, it's a ton of work for the author and reviewer(s) to
check the style in each module and make sure that each hunk uses the
right style. You might spot a mistake based on the context in the hunk,
but you often won't.
You may argue that the extra work is worth it so that module owners can
enjoy their personal style preferences. I don't agree.
Note that where ownership has changed over time (i.e. most modules other
than JS), the module style doesn't even necessarily match the module
owner preferences. It's just a lose all around.
> I think the problem here is overstated. Any large-enough project will
> have some style inconsistency.
Sure. The question is whether we view it as a good thing or a bad thing,
whether we try to decrease it or not.
> Is your house the same as your
> neighbors' houses, even if in the same tract? Some important stuff may
> be consistent (power outlet spacing, truss design and load limits,
> etc. etc.) but that is substance not style.
If the layouts are all different and I have to spend a lot of time in
other people's houses blundering around in the dark then it's definitely
a problem.
> If you are a cross-cutting house-patcher (presumably you're from the
> government and you are here to help :-/), I'll still want to have my
> say, or it's not my house.
Don't go all libertarian on me!
> Is a module less analogous to a house and more like a public space
> that has to follow a common style? Anyone who has seen some US public
> spaces blighted by bad architecture theory may join me in demurring.
Please, leave the politics out of this. There are too many confounding
factors.
Pathological overanalogizing? :-)
I think treating modules as "the owner's business" is a mistake. Our
most productive contributors get things done by chasing problems across
module boundaries and fixing them wherever the best fix is found. We do
need clean interfaces to manage complexity, and we do need cohesive
design within modules, but we should still reduce any unnecessary
barriers to working across module boundaries.
Unless you're one of the lucky few to break new ground, you never get
your style preferences anyway even if you're a module owner. Our current
model is unfair as well as harming productivity.
Rob
Brendan Eich
> On 5/8/09 10:18 AM, Brendan Eich wrote:
>
> > Roc, why did the cross-cutting patch not match local style? Did the
> > patch author ignore it (too busy, too important cross-cutting work,
> > what)? How about reviewers?
>
> When you've got a patch that touches N different modules, changing a few
> lines in each one, it's a ton of work for the author and reviewer(s) to
> check the style in each module and make sure that each hunk uses the
> right style. You might spot a mistake based on the context in the hunk,
> but you often won't.
How often does this kind of big change happen?
How often is the style evident in the patch's diff-context not
representative and informative enough?
> You may argue that the extra work is worth it so that module owners can
> enjoy their personal style preferences. I don't agree.
I argue something else: that you can't get everyone following one
style in a large, mature project that takes in old as well as new code
from various upstreams, and really: life is too short to try to
enforce a common style only on "Mozilla-originated" code across the
whole project.
> Note that where ownership has changed over time (i.e. most modules other
> than JS),
Don't ass-u-me too much here: JS's house style has evolved. See
https://wiki.mozilla.org/JavaScript:SpiderMonkey:C%2B%2B_Coding_Style
https://wiki.mozilla.org/JavaScript:SpiderMonkey:C_Coding_Style
> the module style doesn't even necessarily match the module
> owner preferences. It's just a lose all around.
Module owners are skilled and mature enough, usually, to revise style
to suit their taste when it's appropriate to do so.
> > I think the problem here is overstated. Any large-enough project will
> > have some style inconsistency.
>
> Sure. The question is whether we view it as a good thing or a bad thing,
> whether we try to decrease it or not.
Viewing with alarm something we can't effectively change much is a
waste of time.
Norms for social artifacts like shared source code are good, don't get
me wrong. Just a *consistent* style is a win, compared to style chaos
(which we have in some modules, even living modules).
I don't think we disagree on good, better, best, but I am not going to
stop more important work to police uniform style. As bsmedberg pointed
out, reviewers already do work to uphold style consistency. Perhaps
the major reviewers can just add some effort over time to harmonize
discordant style?
> > Is your house the same as your
> > neighbors' houses, even if in the same tract? Some important stuff may
> > be consistent (power outlet spacing, truss design and load limits,
> > etc. etc.) but that is substance not style.
>
> If the layouts are all different and I have to spend a lot of time in
> other people's houses blundering around in the dark then it's definitely
> a problem.
Why are you in your neighbors house in the dark!?
I really do object to blind cross-cutting super-hero patches. We
require review for those too. Context shows prevailing style. Follow
it or the patch will be nit-picked until fixed.
> > Is a module less analogous to a house and more like a public space
> > that has to follow a common style? Anyone who has seen some US public
> > spaces blighted by bad architecture theory may join me in demurring.
>
> Please, leave the politics out of this. There are too many confounding
> factors.
Whatever that means, we are clearly facing confounders and non-shared
value prioritization schemes, if not actual values. This is *all*
about politics -- as in the good of the _polis_, the common good. It's
also about the "art of the possible". Do not try to slap technology
fixes on it. Until we have structure editors with personal pretty-
printing and input-styling automation (never!) this is a social
problem.
[snip]
> > I hope this helps, but I suspect if we're ratholing on this topic,
> > then something else is wrong. What might that "something else" be?
>
> Pathological overanalogizing? :-)
You cited many of my paragraphs -- thanks, helps reinforce my point.
But pathological over-citing aside, analogies or comparisons to
tangible goods that one might "own" is appropriate. You don't get good
maintenance of code by making it "everyone's" problem. This is
something I've seen over my career, and over Mozilla's lifetime as a
project, ad nauseum.
> I think treating modules as "the owner's business" is a mistake. Our
> most productive contributors get things done by chasing problems across
> module boundaries and fixing them wherever the best fix is found.
Yes, and our best hackers do this while respecting local style, which
is not wildly different across most modules -- and for good reason.
> We do
> need clean interfaces to manage complexity, and we do need cohesive
> design within modules, but we should still reduce any unnecessary
> barriers to working across module boundaries.
This is all great, but how?
> Unless you're one of the lucky few to break new ground, you never get
> your style preferences anyway even if you're a module owner. Our current
> model is unfair as well as harming productivity.
Unfair to whom? The module owner who can't justify a style change amid
other work? How is that "unfair"? Or are you asking for a free style
change to suit your tastes from someone else? I think you just got
more uselessly "political" by dragging "fairness" into this than
anything I wrote ever did.
I maintain we are arguing precisely about a shared notion of common
good, to wit: good style. We may have to hash out bracing style more
than indentation or comment style, but these are big ones. Also
typename mode-cuddling vs. declarator name mode-cuddling, and some
specifics of function/method layout. But if we are not far apart in
the main, then by all means let's get reviewers to nudge code toward a
common style.
In no case would we have a flag day to (semi-automatically or
manually) restyle everything to be "fair" or whatever, so I am really
done wasting time on this. If you are not going to work on a common
style guide analogous to the JS ones, which cite Google's chromium
guide, then I'm going to ignore this thread. It is starting to smack
of someone trying to get others to change their style by fiat. There
is no free lunch in this world.
So, what's the action item?
/be
Brendan Eich
wrote:
> But looking at a more down to earth argument, I believe it is easier for
> everyone if we keep the same standard across modules.
Clearly it is easier, all else equal, for newcomers and cross-module
hackers. The question is whether having one standard across all the
modules whose code we originate ("own", sorry but it fits -- e.g., we
don't own Cairo) is easier for the owners. Two main difficulties:
1. Legacy: not all modules agree, even if each is self-consistent. A
ton of cleanup would be needed, which would be low priority relative
to other work. So it wouldn't get done all at once or quickly, so the
appearance of a lack of standard would continue. But a common style
standard would still help as something to point to and work toward.
2. Disagreement: not all module owners agree, particularly on things
like mFoo vs. foo member names, T* p vs. T *p type/declarator mode-
cuddling, and } else { vs. }\n<indentation-goes-here>>else {, etc.
These are sometimes intensely personal in low-level ways, as in, wired
into one's fingers and other muscle memory. Different styles have
advocates who can make a good case for their faves. Picking one and
imposing it risks alienating owners and would-be owners.
I think dbaron's +∞-rated (by me) post really was onto something: Be
Bold (wikipedia) but also: Be Thoughtful. Blind patching across
modules is not thoughtful enough if it can't follow prevailing style.
I wouldn't trust it as a reviewer, just on that basis. I might be
happy to find it otherwise fine and correct, but doing violence to
prevailing style (even if not a common Mozilla-wide style) would raise
a flag.
If for the bulk of our code we get a common C++ style manual that most
code today actually follows, great! But I suspect it would not have
much more in it than that MDC page has. And from this thread it's
clear some people want a lot more detailed normative specification of
good style.
/be
Robert O'Callahan
> On Aug 4, 3:40 pm, Robert O'Callahan<rob...@ocallahan.org> wrote:
>> When you've got a patch that touches N different modules, changing a few
>> lines in each one, it's a ton of work for the author and reviewer(s) to
>> check the style in each module and make sure that each hunk uses the
>> right style. You might spot a mistake based on the context in the hunk,
>> but you often won't.
>
> How often does this kind of big change happen?
Not often enough, I think. They're certainly the minority of changes by
lines, but they're probably a lot more important than most. The barrier
to getting these projects done is already quite high. I'd hate to raise it.
> How often is the style evident in the patch's diff-context not
> representative and informative enough?
I don't know.
For the reviewer's part, your eyes inevitably glaze over while paging
through reams of similar-looking changes. You're going to miss stuff. If
you require a much higher level of attention, these reviews are going to
be even more gruelling than they alreayd are, and be even more of a
bottleneck than they already are.
>> Note that where ownership has changed over time (i.e. most modules other
>> than JS),
>
> Don't ass-u-me too much here: JS's house style has evolved. See
>
> https://wiki.mozilla.org/JavaScript:SpiderMonkey:C%2B%2B_Coding_Style
> https://wiki.mozilla.org/JavaScript:SpiderMonkey:C_Coding_Style
So? What I said was that unlike JS, most modules have changed owners, so
the current owner has no say in the prevailing style of "their" module.
>> the module style doesn't even necessarily match the module
>> owner preferences. It's just a lose all around.
>
> Module owners are skilled and mature enough, usually, to revise style
> to suit their taste when it's appropriate to do so.
Nobody mass-restyles their module to suit themselves. Don't we all agree
that's a good thing?
>>> I think the problem here is overstated. Any large-enough project will
>>> have some style inconsistency.
>> Sure. The question is whether we view it as a good thing or a bad thing,
>> whether we try to decrease it or not.
>
> Viewing with alarm something we can't effectively change much is a
> waste of time.
We can effectively change it over time. For one thing, we could ensure
that new modules adhere to some project style.
> Why are you in your neighbors house in the dark!?
Because his house is broken and waiting for him to come home to fix it
is inefficient for the project.
> Yes, and our best hackers do this while respecting local style, which
> is not wildly different across most modules -- and for good reason.
It's different enough that I have to think about it all the time.
> Unfair to whom? The module owner who can't justify a style change amid
> other work? How is that "unfair"? Or are you asking for a free style
> change to suit your tastes from someone else? I think you just got
> more uselessly "political" by dragging "fairness" into this than
> anything I wrote ever did.
A few people get to work in their preferred style because they happened
to create new modules and still be active there. Everyone else gets to
suck it up.
> In no case would we have a flag day to (semi-automatically or
> manually) restyle everything to be "fair" or whatever, so I am really
> done wasting time on this. If you are not going to work on a common
> style guide analogous to the JS ones, which cite Google's chromium
> guide, then I'm going to ignore this thread. It is starting to smack
> of someone trying to get others to change their style by fiat. There
> is no free lunch in this world.
We already have a style guide.
> So, what's the action item?
1) Tighten up the style guide to specify project-wide standards for
things we vary on today: braces, indent, etc.
2) Require that style be followed for all new code where legacy
consistency does not apply.
3) Consider how and where we can opportunistically reformat code.
That won't help much in the short term, but it's a start in the right
direction.
Rob
Robert O'Callahan
> 2. Disagreement: not all module owners agree, particularly on things
> like mFoo vs. foo member names, T* p vs. T *p type/declarator mode-
> cuddling, and } else { vs. }\n<indentation-goes-here>>else {, etc.
> These are sometimes intensely personal in low-level ways, as in, wired
> into one's fingers and other muscle memory. Different styles have
> advocates who can make a good case for their faves. Picking one and
> imposing it risks alienating owners and would-be owners.
I said it in my other post but I think it bears saying again: very few
module owners actually get to impose their preferences on their module.
You won't alienate me by imposing a style on layout, since I had no say
in its style in the first place.
The only would-be owners who are going to be alienated are the ones who
show up with new modules prewritten. That's ... rare.
Rob
Brendan Eich
> On 5/8/09 11:03 AM, Brendan Eich wrote:
> > How often does this kind of big change happen?
>
> Not often enough, I think. They're certainly the minority of changes by
> lines, but they're probably a lot more important than most. The barrier
> to getting these projects done is already quite high. I'd hate to raise it.
It may be that we need consistent style to make it easier to land
cross-cutting changes, I agree (without evidence). But we won't
restyle legacy code any time soon, so this is a weak argument even
without evidence.
> >> Note that where ownership has changed over time (i.e. most modules other
> >> than JS),
>
> > Don't ass-u-me too much here: JS's house style has evolved. See
>
> >https://wiki.mozilla.org/JavaScript:SpiderMonkey:C%2B%2B_Coding_Style
> >https://wiki.mozilla.org/JavaScript:SpiderMonkey:C_Coding_Style
>
> So? What I said was that unlike JS, most modules have changed owners, so
> the current owner has no say in the prevailing style of "their" module.
Here's "So?": JS style has evolved over time, so has style in other
modules. I cite htmlparser in particular, where mrbkap has done a lot
to get rid of rickg's insane original style. In xpconnect, new files
have used saner jst+mrbkap style than less sane jband style. But we
kept jband-originated files consistent for a greater good, if not the
ultimate greater good you crave (cvs blame, for one!).
> > Module owners are skilled and mature enough, usually, to revise style
> > to suit their taste when it's appropriate to do so.
>
> Nobody mass-restyles their module to suit themselves. Don't we all agree
> that's a good thing?
See above. Part of ownership is upkeep, including restyling, even if
only in new files. You propose only new files be restyled too, so we
must agree here!
> > Viewing with alarm something we can't effectively change much is a
> > waste of time.
>
> We can effectively change it over time. For one thing, we could ensure
> that new modules adhere to some project style.
What I was getting at is the problem of variation in style, esp.
bracing style. WebKit code shows some variation here. You can't fix
some things.
> > Why are you in your neighbors house in the dark!?
>
> Because his house is broken and waiting for him to come home to fix it
> is inefficient for the project.
1. Turn on the lights.
2. Back off if a competent owner shows up.
3. Call the police (me).
Otherewise, keep out!
> > Yes, and our best hackers do this while respecting local style, which
> > is not wildly different across most modules -- and for good reason.
>
> It's different enough that I have to think about it all the time.
"all the time" seems exagerrated, but worse: since we won't flag-day
the legacy restyling, you'll still have the problem. Or do you propose
mixing the new common indentation/bracing style into existing files
that do not follow it? Four space indentation units in two-space c-
basic-offset files?!
> A few people get to work in their preferred style because they happened
> to create new modules and still be active there. Everyone else gets to
> suck it up.
False, see above. Or else self-imposed: heal thyself.
> We already have a style guide.
Is the style guide failing to prescribe indentation and brace style,
or wisely avoiding the unprescribable? Ok, let's find out. I predict
A. four-space c-basic-offset will prevail.
B. brace wars will waste time and leave inconsistencies at least on
the scale of those in WebKit code.
> 1) Tighten up the style guide to specify project-wide standards for
> things we vary on today: braces, indent, etc.
Someone propose a strawman. Roc made his proposal to me in IRC, I
countered with the jst-ish simplification of it for bracing: brace
everything (Doug Crockford recommends this style to avoid dangling
else and not have to think or read harder).
Four-space c-basic-offset should be the one true indentation unit --
anyone disagree?
> 2) Require that style be followed for all new code where legacy
> consistency does not apply.
Aha! So cross-cutting patchers must still attend to context.
> 3) Consider how and where we can opportunistically reformat code.
>
> That won't help much in the short term, but it's a start in the right
> direction.
Let's start with c-basic-offset: 4. I'll believe brace agreement when
I see it.
/be
Brendan Eich
> On 5/8/09 11:18 AM, Brendan Eich wrote:
>
> > 2. Disagreement: not all module owners agree, particularly on things
> > like mFoo vs. foo member names, T* p vs. T *p type/declarator mode-
> > cuddling, and } else { vs. }\n<indentation-goes-here>>else {, etc.
> > These are sometimes intensely personal in low-level ways, as in, wired
> > into one's fingers and other muscle memory. Different styles have
> > advocates who can make a good case for their faves. Picking one and
> > imposing it risks alienating owners and would-be owners.
>
> I said it in my other post but I think it bears saying again: very few
> module owners actually get to impose their preferences on their module.
> You won't alienate me by imposing a style on layout, since I had no say
> in its style in the first place.
Same went for mrbkap with htmlparser, but he changed style over time.
Why was he among the "very few" who "get" (by what means?) to impose
their style preferences?
> The only would-be owners who are going to be alienated are the ones who
> show up with new modules prewritten. That's ... rare.
They'd be exempt under current rules. I wonder why we would turn them
away only for style revanchism. I would not.
/be
Brendan Eich
> > >> Note that where ownership has changed over time (i.e. most modules other
> > >> than JS),
>
> > > Don't ass-u-me too much here: JS's house style has evolved. See
>
> > >https://wiki.mozilla.org/JavaScript:SpiderMonkey:C%2B%2B_Coding_Style
> > >https://wiki.mozilla.org/JavaScript:SpiderMonkey:C_Coding_Style
>
> > So? What I said was that unlike JS, most modules have changed owners, so
> > the current owner has no say in the prevailing style of "their" module.
>
> Here's "So?": JS style has evolved over time, so has style in other
> modules.
Let me add one point, in case you missed it: I don't like everything
in 1996-era js/src/js*.[ch] style -- who would, even if he once did?
That was a long time ago!
JS style has changed. It keeps changing. It definitely does not suit
all newcomers, as you say, but no one style would.
Ok, fair enough: you are just asking for such a "neutral" or common
style for all new code, with cleanups to existing files as possible
over time.
I reply that we may get c-basic-offset:4 through easily, but bracing
style less so, with mixed results. Worth doing? Probably if we can get
reviewers to accept patches to existing files that use the new-and-
common bracing style for new code.
In that light, what should the new style be? Always-brace probably
wins because most conservative. But I invite others' comments.
Beyond indentation and bracing, the thorny territories of fine-grained
type-mode-declarator spacing, and function definition spacing, and
other such briar-patches, lie.
/be
Zack Weinberg
>
> Let's start with c-basic-offset: 4. I'll believe brace agreement when
> I see it.
I don't care about brace style as long as nobody makes me write
}
else {
but I am going to raise a tongue-firmly-in-cheek objection to
c-basic-offset:4 with my only justification being that it is not the
emacs default. Or are you volunteering to add a modeline to every
file? ;-)
zw
Andrew Sutherland
> For the reviewer's part, your eyes inevitably glaze over while paging
> through reams of similar-looking changes. You're going to miss stuff. If
I'd like to plug my prototype reviewboard/bugzilla integration to help
deal with the scenario where the included context is insufficient.
Since reviewboard actually retrieves the original file, it is able to
provide (expandable) full context around each change.
http://www.visophyte.org/blog/2009/06/20/review-board-and-bugzilla-reviews-take-2/
Andrew
Brendan Eich
> Brendan Eich <bren...@mozilla.org> wrote:
>
> > Let's start with c-basic-offset: 4. I'll believe brace agreement when
> > I see it.
>
> I don't care about brace style as long as nobody makes me write
>
> }
> else {
I agree on that one -- always-brace does not address the else-cuddling
issue. I predict even more controversy than always-brace engenders!
(FYI and of no particular relevance, I agree with you on this one --
K&R and dmr before them cuddled } else { and so do I.)
> but I am going to raise a tongue-firmly-in-cheek objection to
> c-basic-offset:4 with my only justification being that it is not the
> emacs default. Or are you volunteering to add a modeline to every
> file? ;-)
That's not even a dehydra (oink) patch generation task, just sed or
perl. I don't volunteer though -- roc already did :-P.
/be
Daniel Holbert
> Brendan Eich <bre...@mozilla.org> wrote:
>>
>> Let's start with c-basic-offset: 4. I'll believe brace agreement when
>> I see it.
>
> c-basic-offset:4 with my only justification being that it is not the
> emacs default.
Here are two more not-entirely-serious-but-still-worth-considering
objections to standardizing on "c-basic-offset: 4":
(A) Currently, the Coding Style guide on MDC recommends using a modeline
with "c-basic-offset: 2" in new files:
https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide#Mode_Line
(B) Currently, mozilla-central has three tomes as many instances of
"c-basic-offset: 2" compared to "c-basic-offset: 4":
$ grep -r "c-basic-offset: 2" . | wc -l
7744
$ grep -r "c-basic-offset: 4" . | wc -l
2570
$ grep -r "c-basic-offset: [^2^4]" . | wc -l
8
So, it seems to me that standardizing on "c-basic-offset: 4" would
represent a much bigger shift than standardizing on "c-basic-offset: 2",
project-wide. (Not that this necessarily constitutes a strong argument
against it.)
</bikeshedding>
~Daniel
Brendan Eich
> On Aug 4, 6:25 pm, Zack Weinberg <zweinb...@mozilla.com> wrote:
> > I don't care about brace style as long as nobody makes me write
>
> > }
> > else {
>
> I agree on that one -- always-brace does not address the else-cuddling
> issue. I predict even more controversy than always-brace engenders!
>
> (FYI and of no particular relevance, I agree with you on this one --
> K&R and dmr before them cuddled } else { and so do I.)
Oops, I agreed twice with you ;-).
What I meant the first time was to acknowledge your post calling to
light the else-cuddling issue as separate from always-brace.
/be
Daniel Holbert
> (B) Currently, mozilla-central has three tomes as many instances of
> "c-basic-offset: 2" compared to "c-basic-offset: 4":
er, s/tomes/times/ :)
John J. Barton
> So, it seems to me that standardizing on "c-basic-offset: 4" would
> represent a much bigger shift than standardizing on "c-basic-offset: 2",
> project-wide.
Be politic and share the pain: c-basic-offset: 3.
jjb
L. David Baron
It's sometimes tempting.
I'm a fan of 4-space indent, but there's one thing that drives me
crazy about it, which is multi-line if-conditions (for this example,
just pretend all the things inside were long so I had to wrap):
if (a == b ||
c == d ||
--i == 0) {
j++;
g = h;
}
I can't stand this, since it's hard to see where the condition ends
and the code inside it starts. I sometimes just drop the opening
brace onto its own line, even though that's against local style.
-David
Joshua Cranmer
> I'm a fan of 4-space indent, but there's one thing that drives me
> crazy about it, which is multi-line if-conditions (for this example,
> just pretend all the things inside were long so I had to wrap):
>
> if (a == b ||
> c == d ||
> --i == 0) {
> j++;
> g = h;
> }
One of the reasons I like 2-space indent is that you can do this more
easily:
if (a == b ||
c == d ||
--i == 0) {
j++;
g = h;
}
One coding standard guideline stipulates that if-blocks (and other
control structures) indents two times the normal width if you're in the
condition portion.
I'm not necessarily in favor of 2-space indent over 4-space, though (my
default shiftwidth is 4, so I only go to 2 for Mozilla stuff).
Brendan Eich
> On Tuesday 2009-08-04 19:54 -0700, John J. Barton wrote:
>
> > Daniel Holbert wrote:
> >> So, it seems to me that standardizing on "c-basic-offset: 4" would
> >> represent a much bigger shift than standardizing on "c-basic-offset: 2",
> >> project-wide.
>
> > Be politic and share the pain: c-basic-offset: 3.
>
> It's sometimes tempting.
>
> I'm a fan of 4-space indent, but there's one thing that drives me
> crazy about it, which is multi-line if-conditions (for this example,
> just pretend all the things inside were long so I had to wrap):
>
> if (a == b ||
> c == d ||
> --i == 0) {
> j++;
> g = h;
>
> }
>
> I can't stand this, since it's hard to see where the condition ends
> and the code inside it starts. I sometimes just drop the opening
> brace onto its own line, even though that's against local style.
I've done this too, or felt the urge. Norris Boyd introduced it into
SpiderMonkey and used it in Rhino. It makes graphical sense.
Lately I try to avoid it by commenting in the consequent with a major
comment:
if (some &&
overlong &&
condition) {
/*
* Blah blah blah.
*/
. . .
}
which helps avoid the intentional opening brace misplacement.
Does this not seem like one of many fine points a style guide could
try to resolve normatively, and fail as often as it succeeds? Add in
the legacy code that won't change quickly, and it seems to me we can
easily exceed diminishing returns.
Nevertheless, perhaps we can make progress to this point:
1. c-basic-offset: 4 (I know, 2 predominates but 4 seems more popular
-- speak up if you disagree)
2. always-brace.
3. } else { cuddling style
If everyone reading who can commit new files to hg.mozilla.org can
agree on this much, then we can add it to the style guide and try to
make it stick.
If we can't agree on this much then I'm going to say itoldyaso!
/be
Gavin Sharp
> 1. c-basic-offset: 4 (I know, 2 predominates but 4 seems more popular
> -- speak up if you disagree)
I find dbaron's concern ("if (" is 4 characters) and the fact that
2-space is currently more common to be compelling arguments in favor
of 2-space indentation, and I personally prefer it. But I also work
mostly in JS code, where the vast majority (>95%?) of our files use
2-space indentation.
> 2. always-brace.
>
> 3. } else { cuddling style
I can live with both of these (2. is tolerable, 3. matches my preference).
Gavin
Robert O'Callahan
This discussion was not originally about whether I have a magic wand to
restyle large swathes of code. I made the claim that the model we have
had where module owners get to choose style to suit themselves,
especially when they're breaking new ground, is worse than requiring
them to follow a project style when that doesn't conflict with legacy
constraints. I am defending that claim, despite the fact that I can
change few facts on the ground at this time.
Rob
Robert O'Callahan
> On Tue, Aug 4, 2009 at 11:43 PM, Brendan Eich<bre...@mozilla.org> wrote:
>> 1. c-basic-offset: 4 (I know, 2 predominates but 4 seems more popular
>> -- speak up if you disagree)
>
> I find dbaron's concern ("if (" is 4 characters) and the fact that
> 2-space is currently more common to be compelling arguments in favor
> of 2-space indentation, and I personally prefer it. But I also work
> mostly in JS code, where the vast majority (>95%?) of our files use
> 2-space indentation.
Most of layout is 2-space too. I vote for 2-space.
But I'd flip a coin if it helped increase consistency.
Rob
Robert O'Callahan
> On Aug 4, 5:06 pm, Robert O'Callahan<rob...@ocallahan.org> wrote:
>> On 5/8/09 11:18 AM, Brendan Eich wrote:
>>> 2. Disagreement: not all module owners agree, particularly on things
>>> like mFoo vs. foo member names, T* p vs. T *p type/declarator mode-
>>> cuddling, and } else { vs. }\n<indentation-goes-here>>else {, etc.
>>> These are sometimes intensely personal in low-level ways, as in, wired
>>> into one's fingers and other muscle memory. Different styles have
>>> advocates who can make a good case for their faves. Picking one and
>>> imposing it risks alienating owners and would-be owners.
>> I said it in my other post but I think it bears saying again: very few
>> module owners actually get to impose their preferences on their module.
>> You won't alienate me by imposing a style on layout, since I had no say
>> in its style in the first place.
>
> Same went for mrbkap with htmlparser, but he changed style over time.
> Why was he among the "very few" who "get" (by what means?) to impose
> their style preferences?
I don't know. Changing style incrementally violates the rule of
maintaining local style consistency. I've never seen anyone do a
big-bang style change.
>> The only would-be owners who are going to be alienated are the ones who
>> show up with new modules prewritten. That's ... rare.
>
> They'd be exempt under current rules. I wonder why we would turn them
> away only for style revanchism. I would not.
I'd be conflicted, but fortunately, this never happens.
Rob
Neil
> One of the reasons I like 2-space indent is that you can do this more
> easily:
> if (a == b ||
> c == d ||
> --i == 0) {
> j++;
> g = h;
> }
>
> One coding standard guideline stipulates that if-blocks (and other
> control structures) indents two times the normal width if you're in
> the condition portion.
Presumably not ours then; at least, I thought (possibly incorrectly)
that we're just indenting to the matching parentheses e.g.
if (a == b &&
(c == d ||
e == f))
--
Warning: May contain traces of nuts.
Robert Kaiser
> One of the reasons I like 2-space indent is that you can do this more
> easily:
That is one reason why I think 2-space indent is the only true variant,
next to the fact that anything resulting in more than 20 spaces at the
beginning of a line is just crazy, and we tend to get into things deeper
than 5 levels in JavaScript quite easily.
Note that my opinion is probably not that important, I don't do much
code and if so, then only in JS land.
Robert Kaiser
Robert Kaiser
> Four-space c-basic-offset should be the one true indentation unit --
> anyone disagree?
My voice doesn't count much here as I don't do much code and if so only
in JavaScript, but especially there it's not uncommon to go deeper than
5 levels of indentation, and more than 20 spaces at the start of a
hopefully 80-char-clamped line looks very crazy and IMHO makes a lot of
code much uglier than needed.
From where I stand, 2-space indentation for blocks is much more useful
(though IMHO using 4-space within that style for line contiuations is
useful to know apart block indentation and line continuation easily).
Robert Kaiser
Boris Zbarsky
> I don't know. Changing style incrementally violates the rule of
> maintaining local style consistency. I've never seen anyone do a
> big-bang style change.
For what it's worth, there have been file-at-a-time style cleanups in
content. Not necessarily style changes, but removal of all
inconsistencies with jst-style (which in some files was 1/3 to 1/2 of
the lines).
-Boris
belt...@mozilla.com
style, and lessons to be learned from how Mozilla has succeeded and
failed to apply them in the past.
My impression is that if this is to really move forward, someone needs
to take ownership of the issue, create a proposal and perhaps some
formatting tools to assist in the transition, and get it reviewed and
approved by the community peers and module owners, and then placed
somewhere easy to reference for new contributors.
Brendan might be a good person to nominate project leads for this.
cheers,
mike
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
dbradley
> I can think up several potential arguments
> * it's harder to configure IDEs
> * it's hard to copy/paste code between modules
I'm all in favor of anything that makes it harder to cut and paste
code ;-)
I imagine the intent of the "When in Rome" rule was 1. to keep people
from making noisy style nit changes. 2. If someone or group was
willing to contribute a module they weren't going to get hit with a
lot of little nits during the review
If consistent formatting is important to people then maybe someone
could spend the effort to find/build a tool to format code to match
the style guide.
David
dbradley
> if (a == b ||
> c == d ||
> --i == 0) {
> j++;
> g = h;
>
> }
>
> I can't stand this, since it's hard to see where the condition ends
> and the code inside it starts. I sometimes just drop the opening
> brace onto its own line, even though that's against local style.
One of the reasons I've never understood why people stick to the K&R
style braces. Evening after working with it for years, I just find it
difficult to follow. The extra lines needed for braces in the same
column never caused me much grief.
David Bradley
Mike Kristoffersen
I'm a bit sad to see that the discussion about whether or not we should
have a common coding standard is diverging into discussions about the
actual details of the coding standard, it would be better to keep them
in separate threads.
One reason for this is that the discussion is pointless in this forum if
we can't agree to have a common coding standard, the other is that it is
things like this that makes it so hard to follow the information flow in
Mozilla, as there are absolutely no rules, and you need to follow all
sources if you don't want to miss out on some important
information/discussion - which is a full time job in it self, so I doubt
anyone does this :)
But enough about that - that battle is for another day :)
I agree 100% with dbradley here - keeping the braces on separate lines
helps readability and can make it more easy to spot indentation errors
that could lead to other errors, just one example:
if (something) {
call something();
if (something else)
Do SomethingNew
and something else
}
vs:
if (something)
{
call something();
if (something else)
Do SomethingNew
and something else
}
another argument is that you could claim that the style we use now is
inconsistent, as we have :
functions, switches and cases that has the braces on separate lines, and
classes, for, if, do-while and while statements that have the opening
brace on the same line as the keyword.
^__^
MikeK
Brendan Eich
wrote:
> I'm a bit sad to see that the discussion about whether or not we should
> have a common coding standard is diverging into discussions about the
> actual details of the coding standard, it would be better to keep them
> in separate threads.
This is a discussion group AKA usenet newsgroup. Why not here? It's
not as if we can evaluate the idea of a shared bracing standard
without arguing about particular bracing standards and their trade-
offs.
> One reason for this is that the discussion is pointless in this forum if
> we can't agree to have a common coding standard,
To see whether we can agree, we have to argue about the alternatives
to decide among.
> the other is that it is
> things like this that makes it so hard to follow the information flow in
> Mozilla, as there are absolutely no rules, and you need to follow all
> sources if you don't want to miss out on some important
> information/discussion - which is a full time job in it self, so I doubt
> anyone does this :)
This is one thread of 55 messages. I don't see information overload
yet.
> I agree 100% with dbradley here - keeping the braces on separate lines
> helps readability and can make it more easy to spot indentation errors
> that could lead to other errors, just one example:
You and dbradley are in the minority, AFAICT. Also such errors are
hypothetically rare, as in, I've never seen one.
> another argument is that you could claim that the style we use now is
> inconsistent, as we have :
>
> functions, switches and cases that has the braces on separate lines, and
> classes, for, if, do-while and while statements that have the opening
> brace on the same line as the keyword.
The style guide is in error on switch, it is not self-consistent or
consistent with practice.
I think it is idiosyncratic on braced case blocks too.
Who should fix the style guide? Benjamin?
/be
Benjamin Smedberg
> The style guide is in error on switch, it is not self-consistent or
> consistent with practice.
>
> I think it is idiosyncratic on braced case blocks too.
>
> Who should fix the style guide? Benjamin?
I have made that change.
I was surprised to learn that the style guide prefers
} else if () {
} else {
}
over
}
else if () {
}
else {
}
Since years of Mozilla coding have drilled the second style in and it seems
much more prevalent in our code.
--BDS
Robert Kaiser
> I'm a bit sad to see that the discussion about whether or not we should
> have a common coding standard is diverging into discussions about the
> actual details of the coding standard, it would be better to keep them
> in separate threads.
As other people stated here already, you won't get very far with overly
generic discussions in that community, we're used to discussing concrete
issues - and here we are, doing just that.
Robert Kaiser
Mike Kristoffersen
> On Aug 5, 7:40 am, Mike Kristoffersen <mkristoffer...@mozilla.com>
> wrote:
>> I'm a bit sad to see that the discussion about whether or not we should
>> have a common coding standard is diverging into discussions about the
>> actual details of the coding standard, it would be better to keep them
>> in separate threads.
>
> This is a discussion group AKA usenet newsgroup. Why not here? It's
> not as if we can evaluate the idea of a shared bracing standard
> without arguing about particular bracing standards and their trade-
> offs.
>
I don't mind the discussion being in the newsgroup, I mind that we
discuss indentation or where to place braces in a thread in the
newsgroup that has a heading indicating it's about if we should have one
or multiple coding standards - thats what I mean by threads.
But again, lets not branch into yet another discussion, especially not
under a title about the coding standard ;)
>> One reason for this is that the discussion is pointless in this forum if
>> we can't agree to have a common coding standard,
>
> To see whether we can agree, we have to argue about the alternatives
> to decide among.
Isn't that avoiding the problem? - it sounds kind of like, ok, we will
agree on a single standard if everybody agree on the same rules in the
standard? It's not saying that yes, we need a common standard, no
matter what is in it, or that each module can have its own standard,
that might or might not be the same
>
>> the other is that it is
>> things like this that makes it so hard to follow the information flow in
>> Mozilla, as there are absolutely no rules, and you need to follow all
>> sources if you don't want to miss out on some important
>> information/discussion - which is a full time job in it self, so I doubt
>> anyone does this :)
>
> This is one thread of 55 messages. I don't see information overload
> yet.
you need to count all the blogs, all messages in all the newsgroups, all
comments in bugzilla, all verbal agreements etc. - there are no rules
for where information can be transmitted or stored.
>
>> I agree 100% with dbradley here - keeping the braces on separate lines
>> helps readability and can make it more easy to spot indentation errors
>> that could lead to other errors, just one example:
>
> You and dbradley are in the minority, AFAICT. Also such errors are
> hypothetically rare, as in, I've never seen one.
We might be in a minority, but that should not prevent us in expressing
our opinion, nor do I hope that because some see us as a minority, then
we might not have a point and could be right?
>
>> another argument is that you could claim that the style we use now is
>> inconsistent, as we have :
>>
>> functions, switches and cases that has the braces on separate lines, and
>> classes, for, if, do-while and while statements that have the opening
>> brace on the same line as the keyword.
>
> The style guide is in error on switch, it is not self-consistent or
> consistent with practice.
I was under the impression that we were actually discussing what the
style should be? and that the style guide couldn't be used since it
does not describe any specific modules, and that we anyway had to do
what is allready done in each module?
^__^
Mike
Mike Shaver
Kristoffersen<mkristo...@mozilla.com> wrote:
> Isn't that avoiding the problem? - it sounds kind of like, ok, we will agree
> on a single standard if everybody agree on the same rules in the standard?
> It's not saying that yes, we need a common standard, no matter what is in
> it, or that each module can have its own standard, that might or might not
> be the same
There's no point in saying "we must have a standard for X" if no
standard is going to meet our requirements. Premature standardization
is the bane of many technical pursuits, I see no reason that we should
indulge in it here. The best standards codify existing,
understood-workable practices to reduce barriers to entry and improve
interoperability.
Providing examples of potential standardization -- as has been shown
quite well in this thread, some elements may be easier to get to
standardization on (and honouring of that standard!) than others -- so
that they can be concretely discussed is much more productive than
arguing about some abstract meta-good that comes from complete, but
unattainable, uniformity.
It was interesting to me to see Stuart come out in favour of uniform
style, when he was such a strong exponent of a major change from our
standard coding practices, in the form of use of STL containers in one
of his modules. If you're concerned that the voice of the minority
might be lost in these discussions, you might want to consider what
the effects on minority dissent would be if we were to adopt a
project-wide coding style a priori, and then have to define the
details of it!
Mike
Mike Kristoffersen
I'm not sure I get your point - are you saying it would be better if I
just stated that "I think the title of a thread should express what is
being discussed in that thread, and I don't think that is what is
happening here"?
Brendan Eich
> On 8/5/09 11:07 AM, Brendan Eich wrote:
>
> > The style guide is in error on switch, it is not self-consistent or
> > consistent with practice.
>
> > I think it is idiosyncratic on braced case blocks too.
>
> > Who should fix the style guide? Benjamin?
>
> I have made that change.
Thanks.
The case block with } break; on the same line is also unusual. I don't
remember seeing real code do that.
Some of this is too fine a point to dictate, but exemplary code is not
harmful. My point is that people should have realistic expectations
about adoption and attention to detail. I've seen the vaunted WebKit
code (fine code!) be less worried about utterly consistent brace style
than we are being here.
> I was surprised to learn that the style guide prefers
>
> } else if () {
> } else {
> }
>
> over
>
> }
> else if () {
> }
> else {
> }
>
> Since years of Mozilla coding have drilled the second style in and it seems
> much more prevalent in our code.
I'm not so sure about that. DOM and JS including XPConnect use } else
{ -- it's part of K&R style used often.
$ grep -r '} else {' . | wc -l
3436
$ grep -r '[^}] else {' . | wc -l
188
/be
Mike Shaver
No, he's saying that to answer the question of the title "should we
have a common coding standard in Mozilla?" we are looking at the
specifics of what such a standard might specify, what it might not,
and how those choices would affect different areas of the code. I
certainly wouldn't be in a position to make up my own mind on the
question without looking at how different choices for the standard
would impact my work and that of others I observe. Perhaps that
indicates that I lack creativity or the ability to reason at a proper
level about such over-arching changes, but I doubt I'm unique in
wanting some specific examples of changes to play with in my head
before agreeing that unifying on a single coding style has benefits
that outweigh its costs.
Compare "should we convert the Mozilla codebase to a single
programming language?" -- would you expect that such a discussion
could be meaningfully conducted without discussion of specific
constructs, which version of C#/C++/JS we would use, what compiler and
runtime, the experiences of other projects working in the languages,
etc.?
Mike
Brendan Eich
wrote:
Titles are servants, not masters. In order to decide whether to
standardize, we need to evaluate alternatives. Standards (like titles)
are not ends in themselves.
We're pointing down toward the earth here, like Aristotle vs. Plato in
"The School of Athens". Pointing at the ideal form is no good in
making concrete progress. You won't necessarily get everyone agreeing
on a single ideal form, in the first place. In the second, many will
want to consider trade-offs before agreeing that there is an
attainable ideal.
Roc already articulated why a coding standard that is normative on
style issues helps. That set of desiderata is clear enough, yet it
does not command universal agreement on having a common style standard
vs. not. (And I have to interject that making copy-paste programming
easier is an anti-goal in my book!)
/be
Brendan Eich
> $ grep -r '} else {' . | wc -l
> 3436
> $ grep -r '[^}] else {' . | wc -l
> 188
Whoops, that was in js, not top of srcdir. Redoing:
$ find . -name '*.cpp' -print | xargs grep '[^}] else {' . | wc -l
2664
$ find . -name '*.cpp' -print | xargs grep '} else {' . | wc -l
5761
K&R still wins.
/be
Mike Kristoffersen
> On Wed, Aug 5, 2009 at 11:52 AM, Mike
> Kristoffersen<mkristo...@mozilla.com> wrote:
>> Isn't that avoiding the problem? - it sounds kind of like, ok, we will agree
>> on a single standard if everybody agree on the same rules in the standard?
>> It's not saying that yes, we need a common standard, no matter what is in
>> it, or that each module can have its own standard, that might or might not
>> be the same
>
> There's no point in saying "we must have a standard for X" if no
> standard is going to meet our requirements. Premature standardization
> is the bane of many technical pursuits, I see no reason that we should
> indulge in it here. The best standards codify existing,
> understood-workable practices to reduce barriers to entry and improve
> interoperability.
I have yet to hear why an argument for a certain indentation is more
valid in one module that another one, or if we put a { on a separate
line or not (ignoring 3'rd party code for a while here).
Hence it comes to a "think", "like", "used to" discussion - to be honest
I'm missing the link from this to having a single standard or not.
The arguments I have heard for discussing specifics are like, ok - we
try to make a single standard, but if we can't agree then we keep
separate standards in the different modules,.. This brings us back to
the more deep question, is it better to have a common standard, knowing
some people will not like it, or to let each module define what standard
they want.
It is my opinion that the above question about one or multiple standards
should be answered in general, and ones opinion on the question should
not be influenced on whether or not ones favorite module can keep ones
personal preferred standard.
> It was interesting to me to see Stuart come out in favour of uniform
> style, when he was such a strong exponent of a major change from our
> standard coding practices, in the form of use of STL containers in one
> of his modules. If you're concerned that the voice of the minority
> might be lost in these discussions, you might want to consider what
> the effects on minority dissent would be if we were to adopt a
> project-wide coding style a priori, and then have to define the
> details of it!
I hope everyone will express their opinion in such a discussion, its
quite pointless to have a discussion if only arguments that follow what
the majority thinks from the beginning are given any weight or listened
to :)
^__^
MikeK
Peter Weilbacher
> I imagine the intent of the "When in Rome" rule was 1. to keep people
> from making noisy style nit changes. 2. If someone or group was
> willing to contribute a module they weren't going to get hit with a
> lot of little nits during the review
If you are worried about putting off newcomers during the review stage,
you could tell him/her about the all nits, still give r+, and fix the
style issues yourself when checking the patch in. Then the new person
learns about the required style, but is not put off because the patch
is shown to have value and the whole process is accelerated a bit.
Peter.
Peter Weilbacher
> We're quite inconsistent throughout our code, and I think it hurts new
> contributors coming in to the project requiring them to learn quite a
> few different styles. I've been working on Mozilla forever, and I've
> almost given up on several JS patches when all the review comments
> came back as style changes. I would really like to see us discuss
> this further and productively, and lets see if we can come up with a
> style guide that can work across modules. I'm not going to suggest we
> move to it immediately, but certainly would suggest that new code
> follow it and that we look at using some analysis tools to change some
> of these things automatically for us.
Do we actually have a coding style document for JS? Because I only know
of https://developer.mozilla.org/En/Developer_Guide/Coding_Style and
that says C/C++ early on and all the examples seem to be C++.
I'm not sure if it makes sense to standardize the style across languages.
Peter.
L. David Baron
> (And I have to interject that making copy-paste programming
> easier is an anti-goal in my book!)
Agreed. But cut+paste (especially if the paste magically clears the
clipboard) is useful.
I've introduced some new files in layout with 4-space indent, and
occasionally run into problems moving code from one to the other
(e.g., between BasicTableLayoutStrategy.cpp and nsTableFrame.cpp),
although nothing =% plus a little hand editing couldn't fix.
So I think it may have been a mistake to try to move that code
towards a style I preferred. Though, in reality, the reformatting
took less than a minute, so maybe it wasn't a problem.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Brendan Eich
> One of the reasons I've never understood why people stick to the K&R
> style braces. Evening after working with it for years, I just find it
> difficult to follow. The extra lines needed for braces in the same
> column never caused me much grief.
It is of course a matter of taste as much as anything. De goose-
caboose, etc. ;-)
Doug Crockford makes an "objective" argument for K&R style, perhaps
you'll find it persuasive (I did). Doug's argument is about JS, but
since we have JS and C++ and sometimes (more over time, we think)
translate from C++ to JS, then all else equal it would win to use the
same style in JS and C++.
The argument is that { must go on the same line as return when
returning an object initialiser:
return {
foo: 42,
bar: "some very long string",
baz: false
};
JS will automatically insert a semicolon if you wrote
return
{
foo: 42,
...
};
leaving a useless block statement full of labeled but otherwise
useless (strict warning!) expression statements. The whole block would
be dead code too, so subject to warning and automatic elimination --
but JS implementations don't all warn or optimize that much, and
anyway developers miss warnings.
Given this requirement, crock's argument is to put { on the same line
as every control keyword that might need a brace.
Of course (really!) function keywords are not control structure
prefixes per se, so function definitions are an exception.
Ok, end of crock's argument.
This is all apples to oranges for folks like you who prefer a clear
{ on its own line indented to start in the same column as the control
keyword. The utility of that placement is something I can understand.
But K&R fans generally view it as marginal, and a big waste of
vertical space, so benefit loses to cost. Yet dbaron's hard case makes
this a delicate trade-off.
/be
Brendan Eich
> On 05.08.2009 15:48, dbradley wrote:
>
> > I imagine the intent of the "When in Rome" rule was 1. to keep people
> > from making noisy style nit changes. 2. If someone or group was
> > willing to contribute a module they weren't going to get hit with a
> > lot of little nits during the review
When in Rome has long-standing precedence in hacker cultures. It's not
much different from collaborating in meat-space, where you try to
blend and not give (minor, even idiomatic) offense, at least not
before you're ready to sweep clean some large-enough space and show
what you can do.
> If you are worried about putting off newcomers during the review stage,
> you could tell him/her about the all nits, still give r+, and fix the
> style issues yourself when checking the patch in. Then the new person
> learns about the required style, but is not put off because the patch
> is shown to have value and the whole process is accelerated a bit.
I do this. I'm afraid that my picking nits with committers was
imitated by some (an older version of timeless, perhaps) and applied
to newcomers' patches. This can be badly off-putting. The peers with
commit access can take this heat, but no point in boring newbies with
it when substantial issues matter more.
/be
Brendan Eich
wrote:
> > You and dbradley are in the minority, AFAICT. Also such errors are
> > hypothetically rare, as in, I've never seen one.
>
> We might be in a minority, but that should not prevent us in expressing
> our opinion, nor do I hope that because some see us as a minority, then
> we might not have a point and could be right?
Who ever said any such thing? There's no system of prior restraint
keeping you from expressing any opinion.
Let's stick to the substantive argument.
> >> another argument is that you could claim that the style we use now is
> >> inconsistent, as we have :
>
> >> functions, switches and cases that has the braces on separate lines, and
> >> classes, for, if, do-while and while statements that have the opening
> >> brace on the same line as the keyword.
>
> > The style guide is in error on switch, it is not self-consistent or
> > consistent with practice.
>
> I was under the impression that we were actually discussing what the
> style should be? and that the style guide couldn't be used since it
> does not describe any specific modules, and that we anyway had to do
> what is allready done in each module?
Why are you borrowing trouble? The style guide already talks about
bracing and indentation a bit, and could be taken as normative if
people can agree. But for people to agree, it has to be sufficiently
self-consistent, and it would help if it matched majority practices.
Minority points of view, even lone cognitivie dissidents, are hugely
valuable in my view. We need them. Indeed my "subsidiarity" policy for
module-owner style "home rule" favors minorities. But the price is
some extra pain and work for cross-cutters and newcomers.
/be
Brendan Eich
> Compare "should we convert the Mozilla codebase to a single
> programming language?" -- would you expect that such a discussion
> could be meaningfully conducted without discussion of specific
> constructs, which version of C#/C++/JS we would use, what compiler and
> runtime, the experiences of other projects working in the languages,
> etc.?
Good analogy, and prescient if I have my way. I believe we should use
our static analysis work to improve the codebase via programming
language leverage (enforce safety properties via compilation and VM
techniques, e.g.). If we do this, then possibly we could have some
code-restyling flag days. Sooner than some might think, too!
This doesn't help settle on common style, but it would deal with the
legacy conflicts and confusions.
/be
Mike Kristoffersen
> On Aug 5, 8:52 am, Mike Kristoffersen <mkristoffer...@mozilla.com>
> wrote:
>>> You and dbradley are in the minority, AFAICT. Also such errors are
>>> hypothetically rare, as in, I've never seen one.
>> We might be in a minority, but that should not prevent us in expressing
>> our opinion, nor do I hope that because some see us as a minority, then
>> we might not have a point and could be right?
>
> Who ever said any such thing? There's no system of prior restraint
> keeping you from expressing any opinion.
>
> Let's stick to the substantive argument.
In retrospect I might have overreacted - when I read your post I read it
as if our argumentation was neglected because we were seen as a
minority, which is what I reacted strongly against - From this post and
re-reading your previous one, I can see that, that was not your point -
which I'm kind of happy to realise :)
>>>> another argument is that you could claim that the style we use now is
>>>> inconsistent, as we have :
>>>> functions, switches and cases that has the braces on separate lines, and
>>>> classes, for, if, do-while and while statements that have the opening
>>>> brace on the same line as the keyword.
>>> The style guide is in error on switch, it is not self-consistent or
>>> consistent with practice.
>> I was under the impression that we were actually discussing what the
>> style should be? and that the style guide couldn't be used since it
>> does not describe any specific modules, and that we anyway had to do
>> what is allready done in each module?
>
> Why are you borrowing trouble? The style guide already talks about
> bracing and indentation a bit, and could be taken as normative if
> people can agree. But for people to agree, it has to be sufficiently
> self-consistent, and it would help if it matched majority practices.
>
> Minority points of view, even lone cognitivie dissidents, are hugely
> valuable in my view. We need them. Indeed my "subsidiarity" policy for
> module-owner style "home rule" favors minorities. But the price is
> some extra pain and work for cross-cutters and newcomers.
>
When talking about "rules" in software, it is for most people (my self
included) mainly about what we believe is the right thing - in
discussing such rules I agree that all parties should be heard and their
argumentation considered (let the best argument win).
When it comes to execution of a given rule set I don't see a need to
favor minorities in the general sense - there should always be room for
exceptions to rules, but it must only happen if there are unique
circumstances - like a "goto" might be acceptable even they are
generally avoided, if you by doing that can avoid heavy nesting in a
function (the point here is that there can be good reasons for not
following a coding standard and in such cases exceptions should be
allowed, it's not my point to start an argumentation about gotos) - I
have yet to see an argument that 4 space indent makes sense in one
module and not in another one (or 2 spaces or whatever).
Btw. I'm sure research could be done, if not all ready done to find the
scientifically optimal indentation/line length, naming convention, etc.
Not that I'm proposing we do that, but it could be an interesting read
if someone did take the time to do scientific research on it :)
Justin Dolske
> I find dbaron's concern ("if (" is 4 characters) and the fact that
> 2-space is currently more common to be compelling arguments in favor
> of 2-space indentation, and I personally prefer it. But I also work
> mostly in JS code, where the vast majority (>95%?) of our files use
> 2-space indentation.
Although I've been using 4-space indents in all the new JS files I've
created. :)
IMO, the benefit of more distinct indentation from 4 spaces is worth the
cost of the "if (" suckyness. 2-space indent has always seemed to me
like an optimization for cramming code onto an 80-column punchcard by
someone who felt guilty using only 1 space.
Justin
Mike Kristoffersen
Its true that even a 2-space indentation easily gives you trouble when
it comes to staying inside a max width of 80 - I'm definitely in favor
of having a max width on our individual code lines (horizontal scrolling
is a killer when reading code), but I'm not sure if a 4 space
indentation with a 160 max width means you get into trouble as fast as a
2 space 80 max width does? (I would guess that has to do with the
average line width excluding indentation being > | < 40)
^__^
Mike
Robert O'Callahan
> I do this. I'm afraid that my picking nits with committers was
> imitated by some (an older version of timeless, perhaps)
Not just the older version.
Rob
Brendan Eich
wrote:
> Its true that even a 2-space indentation easily gives you trouble when
> it comes to staying inside a max width of 80 - I'm definitely in favor
> of having a max width on our individual code lines (horizontal scrolling
> is a killer when reading code), but I'm not sure if a 4 space
> indentation with a 160 max width means you get into trouble as fast as a
> 2 space 80 max width does? (I would guess that has to do with the
> average line width excluding indentation being > | < 40)
Good points. SpiderMonkey stopped before column 80 (columns are
numbered from 1; we stopped at 79 to avoid old Emacsen from putting a
continuation mark in column 80 even if the char there was a newline).
We've moved to 100. We use c-basic-offset: 4.
Logic level plus non-whitespace source line element lengths can
conspire to push either limit but we cope. One exception: we wrap
comments voluntarily before 80, usually (scofflaws exceed 80 but not
by much; interesting Fitts' law corollary to-do with one's head having
a big moment of inertia compared to one's eyes ;-).
Some project (IIRC Linux kernel code, and maybe C-Python) advise no
more than N (small N, 3 or 4) logic levels.
At this point I'm not sure what to do about this thread. The "most
common" style, sticking to indentation, bracing, else-cuddling, and
line limit, may be something like
* c-basic-offset: 2
* always-brace
* } else { (K&R style)
* tw=100 (in vim's modeline)
If people want this in the style guide, then reviewers can start
nagging about it being followed in new code. But new code added file-
wise to an existing module that uses c-basic-offset: 4 (never mind
other values for the above params) will not mesh well in that module,
and I predict the guide will be ignored for such new files in deviant
modules.
I'm out of time on this topic, it's fun but not particularly important
compared to more substantive work -- IMHO. Comments on the strawman
parameter settings above welcome, I'll return to catch up on this
thread as I'm able.
/be
L. David Baron
> Brendan Eich <bre...@mozilla.org> wrote:
>
> > * c-basic-offset: 2
> > * always-brace
> > * } else { (K&R style)
> > * tw=100 (in vim's modeline)
>
> I am very attached to having two independent emacs windows side by side
> on my monitor. On my laptop I can only do this if they are 80 columns
> wide. My gigantic 1920x1200 monitor can handle 100-column windows,
> barely. 120 columns is right out.
I'd like to stick to 80 for three reasons:
(1) the reason above (two 80-column windows on my laptop),
(2) because 80 happens to be the default width of many terminal
applications, and
(3) 100 is a bit harder to enforce, because things don't default to
being 100 columns wide. So people might tend to make their
windows a little bigger than 100 to fit the code that's already
there, and then write code that fits *their* (slightly wider)
window, and the line lengths might gradually creep higher as a
result.
Brendan Eich
> On Friday 2009-08-07 15:16 -0700, Zack Weinberg wrote:
>
>
> > > * c-basic-offset: 2
> > > * always-brace
> > > * } else { (K&R style)
> > > * tw=100 (in vim's modeline)
>
> > On the topic of line length, I am not attached to 80 columns per se, but
> > I am very attached to having two independent emacs windows side by side
> > on my monitor. On my laptop I can only do this if they are 80 columns
> > wide. My gigantic 1920x1200 monitor can handle 100-column windows,
> > barely. 120 columns is right out.
>
> I'd like to stick to 80 for three reasons:
>
> (1) the reason above (two 80-column windows on my laptop),
Igor made this point, it's a compromise (I'm a laptop hacker, I see
the case but feel the heat from c-basic-offset:4 and fairly long
average element-on-line length).
> (2) because 80 happens to be the default width of many terminal
> applications, and
True, still -- this is not likely to change.
> (3) 100 is a bit harder to enforce, because things don't default to
> being 100 columns wide. So people might tend to make their
> windows a little bigger than 100 to fit the code that's already
> there, and then write code that fits *their* (slightly wider)
> window, and the line lengths might gradually creep higher as a
> result.
Yeah, we're on the slippery slope. But I said I'd hold the line at 100
when we adjusted up from SpiderMonkey's historical tw=80, and I mean
it. If the line can't be held I'll keep my word here by going back to
80.
Ok, revised straw non-standard standard:
c-basic-offset: 2
always-brace
} else {
tw=80
/be
Peter Weilbacher
> Ok, revised straw non-standard standard:
>
> c-basic-offset: 2
> always-brace
> } else {
> tw=80
Perfectly matches my habits. :-) Although a hard limit of 80 chars
is often difficult to adhere to, given how long some function names
are.
If you are serious about always-brace, there are a few examples in
the Coding Style document that need revision.
Peter.
Mike Kristoffersen
I can live with 80 too - but as you say it can be a pain with long
function names (and variable names, as most of our function calls are
called on some object).
So keeping an 80 char width might force more work on some people and
cost more vertically and they might not take this "limitation" likely,
are we ready to enforce an 80 char line width and an indent of 2? -It's
an important question as there is no need to make a rule that we are not
going to enforce anyway.
A related question is, are we talking about a cross module set of rules
here or just a recommendation that can be overruled in any module?
^__^
MikeK
Robert Kaiser
> c-basic-offset: 2
> always-brace
> } else {
> tw=80
With 2-space-indent, 80 should be fine, yes, and that combination
happens to be what we're using in very many places anyhow, esp. in JS.
Robert Kaiser
dbradley
> You and dbradley are in the minority, AFAICT. Also such errors are
> hypothetically rare, as in, I've never seen one.
Preface this with I don't really expect to change anything real
regarding braces. It's more an academic exercise on my part, as I
wouldn't expect such a style change to be adopted given the existing
code.
I think it depends on the audience. Outside of system level developers
I find K&R much less used.
What I find mildly humorous is the inconsistency of bracing in that
style. Braces often are not on the same line as the function
definition. And rarely are they on the same line as the class
declaration. That's always puzzled me. Why is it great for control
flow but not for classes and functions.
What I find even more amusing is the energy such trivial things
generate. My previous employer we had the big battle over 2, 3, or 4
space indention.
So while K&R style isn't my favorite, I deal with it and move on. Sure
I might have to spend an extra minute double checking that I have the
correct block, but no big deal.
Life is too short, lets get coding!
Robert O'Callahan
> A related question is, are we talking about a cross module set of rules
> here or just a recommendation that can be overruled in any module?
I think we should enforce it in all new modules, and anywhere where the
style is already hopelessly inconsistent.
Rob
Robert O'Callahan
> c-basic-offset: 2
> always-brace
> } else {
> tw=80
Make it so.
A few more issues that I hit a lot of inconsistency on:
T* foo
vs
T *foo
static void
HelloKitty()
vs
static void HelloKitty()
HelloKitty() {
vs
HelloKitty()
{
For the last one, I think we overwhelmingly prefer the brace on the new
line, so we should probably mandate that. Not sure about the other two.
Rob
Jim Blandy
non-conformant code", meaning "code that was written to specifications
other than those presented by this guide". We incorporate a lot of code
that has upstream maintainers; it seems appropriate to acknowledge that
with some language like Google's.
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Blake Kaplan
> A few more issues that I hit a lot of inconsistency on:
>
> T* foo
> vs
> T *foo
My fingers tend towards the latter style but I can learn if it's deemed
necessary.
> static void
> HelloKitty()
> vs
> static void HelloKitty()
As a vim user, I much prefer the former style. It allows me to easily find the
definition of a function by typing '/^Hello'.
> HelloKitty() {
> vs
> HelloKitty()
> {
>
> For the last one, I think we overwhelmingly prefer the brace on the new
> line, so we should probably mandate that. Not sure about the other two.
Again, vim influences my preferences here since the keystroke [[ finds the
nearest { in column 0 which is an easy way to navigate functions in a file.
--
Blake Kaplan
gNeandr
standard in Mozilla.
I'm sure there is (at least ;-) ... ) one. Can anyone help?
Thinking back to some discussions with the Lightning people I found this:
https://wiki.mozilla.org/Calendar:Style_Guide
Has it any relevance for other Mozilla projects or would it be a good
starting point for the coding standard in Mozilla ??
G�nter
Peter Weilbacher
> Also a lot of arguments have been shared I mis a pointer to a coding
> standard in Mozilla.
> I'm sure there is (at least ;-) ... ) one. Can anyone help?
https://developer.mozilla.org/En/Developer_Guide/Coding_Style
Cheers,
Peter.
dbradley
> > HelloKitty() {
> > vs
> > HelloKitty()
> > {
>
> > For the last one, I think we overwhelmingly prefer the brace on the new
> > line, so we should probably mandate that. Not sure about the other two.
>
> Again, vim influences my preferences here since the keystroke [[ finds the
> nearest { in column 0 which is an easy way to navigate functions in a file.
> --
> Blake Kaplan
Interesting, so this inconsistency in brace preference between
function and blocks is maybe driven by searching. Allowing people to
distinguish between start of a function and start of a block. I think
I'm starting to see some of the draw of some of the style options.
Being more of a mouse guy, the benefits weren't all that apparent.
David
Jim Blandy
Emacs pushes things in the same direction. C-M-a looks for opening
braces in the first column; and I search for function definitions with
'C-s C-j HelloKitty'.
Brendan Eich
> If you are serious about always-brace, there are a few examples in
> the Coding Style document that need revision.
Nothing in the doc is changing just because I posted a non-standard
standard straw-man!
/be
Brendan Eich
> On 8/8/09 1:18 PM, Brendan Eich wrote:
>
> > c-basic-offset: 2
> > always-brace
> > } else {
> > tw=80
>
> Make it so.
Hey, you are not Picard. But I'm Kirk! Time to beam into danger...
> A few more issues that I hit a lot of inconsistency on:
>
> T* foo
> vs
> T *foo
If we pretend * is part of T then one declarator per declaration must
be the rule. This is livable but it requires discipline. In
SpiderMonkey we have a legacy T *p style that can't be overcome
without lots of foolish hand-editing and we're going to stick with it
rather than fight it.
I'm sure we'll have some mixups even in new code. There's no cure but
eternal vigilance and patience. I can document T* p and the one
declarator per declaration rule but I should make a last call for non-
roc and interesting minority/dissident opinions.
> static void
> HelloKitty()
> vs
> static void HelloKitty()
The former, if this is file-static. For in-class declarations and
inline definitions, people prefer the latter and even put the opening
{ on the same line as the introductory storage-class/etc. qualifiers
and function declarator.
>
> HelloKitty() {
> vs
> HelloKitty()
> {
>
> For the last one, I think we overwhelmingly prefer the brace on the new
> line,
Yes.
I will update the style guide in a bit. More comments from outliers/
canaries-in-coal-mines/people-with-interesting-experiences welcome.
Again we are not going to impose this on existing code that has its
own conventions from an "upstream" -- I think this includes js/src/*
-- it definitely includes js/src/nanojit.
I hope we're not going to waste a lot of time redressing existing code
without doing higher-leverage moves. We have tons of competition and
many bigger fish to fry!
/be
/be