[Code health] Consistent naming of Rx streams

@scolsen listened to this podcast after our chat. I agree with most of the suggestions there. Key takeaways (mixed with my own observations):

• There’s no single convention used by everyone, but there are some prevailing trends.
• The getFoo() pattern is dated, a relic of JavaBeans naming conventions.
• Consistent naming >> relying on return types as documentation:
• Doesn’t require developers to look at declaration to understand semantics.
• Prevents signatures from collide if we add an override that returns a different Rx type.

Some ideas/suggestions:

• Use foo() for immutable synchronous accessors (e.g. User user())… There’s also precedent for this in JDK methods like values().
• fooOnce() for Rx types that return a single value and complete (usually Single<>).
• fooStream() for Rx types that are expected to not complete while the application is in a normal state. fooOnceAndStream()` for Rx types that return a single value (the latest?) ASAP and then continue to stream updates while the application is in a normal state.

A similar approach is also described here.

Wdyt? No need to change existing uses now, but new code could use the convention, and we can update existing code once V0 is ready.

@navinsivakumar FYI.

[scolsen]

Ah! Great point to raise! Definitely something we should address. I think the right approach is actually to just fix all the function bodies so that we don’t mix eager/lazy eval rather than use a naming convention. Generally speaking I’m also a fan of eliminating as much of the imperative code that we can (right now we do have quite the amalgam of functional/imperative style). wdyt?

[gino-m]

One other thing; we should also take care when naming fields referencing Subjects backing these streams. It may be tempting (as I did in my previous deleted comment) to name them according to the method convention:

• PublishSubject<User> userStream;
• BehaviorSubject<User> userOnceAndStream;

But recall that the “Once” part is a function of the streams’ behavior, not their underlying type. The first stream could easily be set up to emit a value immediately when the method is called. For that reason, it might be better to just name them for the fact that they’re subjects:

• PublishSubject<User> userSubject; or
• BehaviorSubject<User> userSubject;

This also makes it clear that values can be emitted via those fields by calling userSubject.onNext().

Completable, Maybe, and Single will rarely be used as fields, but I assume we would follow the same convention as for method names (method getUser() returns field user).