Closed Bug 977103 Opened 8 years ago Closed 8 years ago

Prefix LocaleManager's static members with 's'

Categories

(Firefox for Android Graveyard :: General, defect)

All
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: lucasr, Assigned: lucasr)

Details

Attachments

(1 file)

For coding style consistency.
Attachment #8382231 - Flags: review?(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.
(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).
Closing as discussion about the new coding style has started in the mailing list.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Attachment #8382231 - Flags: review?(rnewman)
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.