https://kotlinlang.org logo
Title
v

vitus

08/05/2019, 8:56 PM
Hi people! The CTO of our company is trying to convince our Android team to start prefixing all class names with a three letter uppercase abbreviation of the company’s name. E.g. Company name: Fancy Coffee Roasting Class name: FCRProfileViewModel He’s also an iOS developer, where prefixing seems more reasonable because of the global namespace pollution and conflicts that are caused by not requiring imports, if I’m not mistaken. It also seems more natural as it appears to be some legacy of Objective-C. Apart from the arguments of additional noise that comes with the three uppercase letters and that this pattern is quite uncommon for Kotlin, what would be your arguments against it? We’re also worried that this change will break some of the beauty our IDE supplies, like suggesting names, as variable names aren’t meant to include the prefix.
🔥 1
😂 13
😨 1
🤦‍♂️ 10
j

jw

08/05/2019, 8:58 PM
Does this person understand what packages are and what function they serve?
18
Also, LOL
👆 22
h

hallvard

08/05/2019, 8:58 PM
Don't you have a package name?
Right, Jake, you beat me to it.
com.fancycoffeeroasting.whatever...
b

basher

08/05/2019, 9:04 PM
It's a relic of Obj-C– especially necessary in an App Store env where collisions with Apple's frameworks can happen. Swift is more like Kotlin in this regard. This name-spacing is not needed/wanted/used in that (Swift/Kotlin) ecosystem because the collisions can't happen at the class level.
👍 3
k

karelpeeters

08/05/2019, 9:07 PM
Who made him CTO?
☝️ 5
:trollface: 16
🙃 2
v

vitus

08/05/2019, 9:08 PM
It made me laugh in the beginning as well, but this situation is quite serious to me. He argues that it’s a convention that either both mobile teams have to follow or none. And it seems that the iOS team is ok with it.
m

Mark Murphy

08/05/2019, 9:17 PM
"He argues that it’s a convention that either both mobile teams have to follow or none" -- why? There are countless differences between iOS and Android development. Next, will he say that both teams have to use XCode or nobody can use an IDE?
🤯 1
f

fangzhzh

08/05/2019, 9:18 PM
But why? Does iOS and Android share same language, or tool chain, or design?
v

vitus

08/05/2019, 9:28 PM
Both platforms share most of the design and we pair up quite a lot when implementing features. Still, I see literally zero gain from doing that on Android.
b

basher

08/05/2019, 9:31 PM
When discussing shared concepts, people (in my experience) don't say the prefixes out loud most of the time. Also if this is a new project, presumably you'll use Swift, which doesn't need prefixes, so both code bases will be on the same page…
d

Dico

08/05/2019, 10:20 PM
That's an unreasonable decision because it probably harms the relationship between him and the android team, who (presumably) oppose the idea on the grounds that it A. Sucks to work with B. Isn't necessary C. His argument is very weak (if it is even an argument)
s

Sergey Bondari

08/05/2019, 11:12 PM
Tell him even Swift is not using prefixes anymore
Old fashioned party pooper.
b

basher

08/05/2019, 11:13 PM
B. Isn't necessary
This is the big one. Prefixes were added as a defense mechanism, not because they were cool/interesting/useful. That mechanism is no longer needed and adds unjustifiable cruft
j

Jeremy

08/06/2019, 12:13 AM
Is this the Onion?
c

clarkap

08/06/2019, 12:42 AM
seriously, the 1990's want their CTO back. Next he'll be asking for Hungarian notation.🤣😮
🤣 1
m

Marcelus Trojahn

08/06/2019, 12:52 AM
TBH... I'd just do it and spare me the headache. Picking up fights / not caring is something I learned thru the years... 🤣
j

jw

08/06/2019, 12:53 AM
☝️ Found the CTO
🤤 5
:trollface: 8
m

Marcelus Trojahn

08/06/2019, 12:54 AM
Nope... I don't agree with it as well... I just wouldn't stress about it.
💰 1
s

Sami Eljabali

08/06/2019, 5:09 AM
I agree with Marcelus. Point out the obvious objective reasons once or twice, then if common sense doesn't resolve itself, move on. Pick your battles, cause there's a lot more to come it seems including those that will actually ruin the app.
h

hallvard

08/06/2019, 6:27 AM
I think I would just go with it as well. If your fingers are of a difficult sort, they will sometimes mess up, so
FCRProfileViewModel
will become
FRCProfileViewModel
or even
GVTProfileViewModel
or whatever, and since you use an intelligent IDE, that won't be a problem, and nobody will notice, since your main objective is avoiding naming conflicts (I deliberately omit namespace pollution as an objective, since this actually is a big one of those). Maybe your CTO will notice when/if looking over the code, but then, since he too will use an intelligent IDE, he can change that in a matter of seconds.
l

louiscad

08/06/2019, 6:50 AM
So you can tell your CTO Android developers are not convinced, for all the great reasons mentioned above. You can also demonstrate how packages and named imports in Kotlin make you not have clashes that decades old Obj-C would have.
g

galex

08/08/2019, 8:51 AM
What this CTO wants is commonly known as the Smurf Naming Convention,
When almost every class has the same prefix. IE, when a user clicks on the button, a SmurfAccountView passes a SmurfAccountDTO to the SmurfAccountController. The SmurfID is used to fetch a SmurfOrderHistory which is passed to the SmurfHistoryMatch before forwarding to either SmurfHistoryReviewView or SmurfHistoryReportingView. If a SmurfErrorEvent occurs it is logged by SmurfErrorLogger to ${app}/smurf/log/smurf/smurflog.log
Commonly considered an anti-pattern…
💯 1