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.

Does this person understand what packages are and what function they serve?

Don't you have a package name?

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.

Who made him CTO?

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.

"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?

But why? Does iOS and Android share same language, or tool chain, or design?

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.

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…

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)

Tell him even Swift is not using prefixes anymore

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

Is this the Onion?

seriously, the 1990's want their CTO back. Next he'll be asking for Hungarian notation.🤣😮

TBH... I'd just do it and spare me the headache. Picking up fights / not caring is something I learned thru the years... 🤣

☝️ Found the CTO

Nope... I don't agree with it as well... I just wouldn't stress about it.

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.

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.

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.

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…