https://kotlinlang.org logo
#android
Title
# android
b

brianwernick

02/20/2017, 3:35 PM
Oh man, It makes me so sad we are stuck with that in AOSP
m

mg6maciej

02/20/2017, 3:44 PM
brianwernick: I wouldn't say it's a big deal.
Not even a problem that some app developers like to copy `m`s without thinking too much what's the reason behind it.
b

brianwernick

02/20/2017, 3:45 PM
It isn’t really, I’m just being overly dramatic 🙂
m

mg6maciej

02/20/2017, 3:45 PM
I like to read AOSP code and I was always wondering if there were any discussions regarding the quality of the code.
Like going from thousands lines of code per file on average to hundreds.
b

brianwernick

02/20/2017, 3:47 PM
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.
m

mg6maciej

02/20/2017, 3:52 PM
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.
It was a few years ago, so might be much worse now 😉
b

brianwernick

02/20/2017, 3:54 PM
Haha. I’ve had some pretty bad experiences with foreign devs as well (and a few good ones).
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
m

mg6maciej

02/20/2017, 3:57 PM
This is what you learn after years of doing things the wrong way, when they bite and slow you down...
Or months if you are lucky and have a good mentor, who I, sadly, didn't have.
b

brianwernick

02/20/2017, 4:10 PM
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
r

romainguy

02/20/2017, 7:41 PM
@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
The same applies to things like
@Hide
, they are usually necessities born from practical realities that needed a solution
b

brianwernick

02/20/2017, 7:45 PM
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)
r

romainguy

02/20/2017, 7:46 PM
You might be underestimating the cost and burden of maintaining a public API
While I wish we had made more APIs public, I am also grateful we @hid many, many of them
It’s always easier to make them public later than the other way around
b

brianwernick

02/20/2017, 7:55 PM
I have multiple open source libraries so I do understand the cost and burden of that
4 Views