977103 - Prefix LocaleManager's static members with 's'

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Lucas Rocha (:lucasr)]

For coding style consistency.

Comment 1

[Lucas Rocha (:lucasr)]

Attachment: Prefix LocaleManager's static members with 's' (r=rnewman)

Comment 2

[Richard Newman [:rnewman]]

Lucas, you troublemaker! :D

I oppose, for these reasons:

* Small-scale: this is a 100% static class (no non-static methods). There's zero value to indicating that any of its members are 'especially' static.

* Medium-scale: we already have a syntactic way of indicating that a member is static or non-static: Foo.member versus this.member.

* Large-scale: we have tools to tell us which members are static, just as we have compiler warnings to tell us when we're accessing a static member via an instance, or when a method could be declared as static.

For example, members appear in blue, locals appear in black, and statics are in italics. Doesn't your editor do that? If not, can we fix that problem?


So I propose a counter-proposal: for all new code, use modern coding standards: always use braces, use early returns, don't use a/m/s prefixes. We already do this for ~1/4 of Fennec.

Comment 3

[Lucas Rocha (:lucasr)]

(In reply to Richard Newman [:rnewman] from comment #2)
> Lucas, you troublemaker! :D
> 
> I oppose, for these reasons:
> 
> * Small-scale: this is a 100% static class (no non-static methods). There's
> zero value to indicating that any of its members are 'especially' static.
> 
> * Medium-scale: we already have a syntactic way of indicating that a member
> is static or non-static: Foo.member versus this.member.
> 
> * Large-scale: we have tools to tell us which members are static, just as we
> have compiler warnings to tell us when we're accessing a static member via
> an instance, or when a method could be declared as static.
> 
> For example, members appear in blue, locals appear in black, and statics are
> in italics. Doesn't your editor do that? If not, can we fix that problem?
> 
> 
> So I propose a counter-proposal: for all new code, use modern coding
> standards: always use braces, use early returns, don't use a/m/s prefixes.
> We already do this for ~1/4 of Fennec.

To be honest, I'm not keen on style proposals that starts with: "for all new code, ...". What I mean is: I'm fine with any coding style really, as long as it's consistent.

If you'd like to propose this new style, please do so in our the mailing list and let's port to all our Java code (or at least most of it) to the new style. This should not be a decision we make individually for only certain parts of our code (even though I know this is kinda common in Mozilla).

Comment 4

[Lucas Rocha (:lucasr)]

Closing as discussion about the new coding style has started in the mailing list.