Oh man, It makes me so sad we are stuck with that in AOSP

# android

[brianwernick]

Oh man, It makes me so sad we are stuck with that in AOSP

[mg6maciej]

brianwernick: I wouldn't say it's a big deal.

[mg6maciej]

Not even a problem that some app developers like to copy `m`s without thinking too much what's the reason behind it.

[brianwernick]

It isn’t really, I’m just being overly dramatic 🙂

[mg6maciej]

I like to read AOSP code and I was always wondering if there were any discussions regarding the quality of the code.

[mg6maciej]

Like going from thousands lines of code per file on average to hundreds.

[brianwernick]

Yeah, I have quite a few complaints about the organization (or lack thereof) of the AOSP source. In addition to a few other complaints such as their @Hide annotated methods, etc.

[mg6maciej]

Still the code is better than what developers from other companies do with it. I had a chance to work on Phone app for Samsung R&D. Compared activity classes with AOSP. 6k lines vs 14k lines and a lot of mess added.

[mg6maciej]

It was a few years ago, so might be much worse now 😉

[brianwernick]

Haha. I’ve had some pretty bad experiences with foreign devs as well (and a few good ones).

[brianwernick]

I’ve actually seen similar coding standards from people that go through the 3 week -> 2 month coding schools; as typically no focus is given on code quality or organization

[mg6maciej]

This is what you learn after years of doing things the wrong way, when they bite and slow you down...

[mg6maciej]

Or months if you are lucky and have a good mentor, who I, sadly, didn't have.

[brianwernick]

Yeah, I was on the same boat; I didn’t have a good mentor for organization (or maybe it was that I jumped teams every few weeks) until about 2 years in to my career. Relearning a lot of things was somewhat difficult

[romainguy]

@brianwernick There is a reasoning behind the code organization, and it was actually reorganized a few times, but things evolve and the team is now a couple orders of magnitude larger than 10 years ago and it’s hard to enforce everything. Esp. since in the end the goal is to ship a product

[romainguy]

The same applies to things like @Hide, they are usually necessities born from practical realities that needed a solution

[brianwernick]

The broad organization of the source doesn’t bother me too much, what does bother me is the organization within a file (specifically in the support libraries).

In other areas they make methods private that aren’t doing anything magical (which makes extending to workaround a bug impractical). The @Hide annotation is even worse, they have public methods but don’t let you build against them (I don’t hit that one often, but it’s quite irritating when I do)

[romainguy]

You might be underestimating the cost and burden of maintaining a public API

[romainguy]

While I wish we had made more APIs public, I am also grateful we @hid many, many of them

[romainguy]

It’s always easier to make them public later than the other way around

[brianwernick]

I have multiple open source libraries so I do understand the cost and burden of that