Reverse class naming

[luciapayo]

Traditionally the convention for naming classes was feature + component, for instance SearchFragment, which made sense because the packaging was made by component. In this project the packaging is done by feature which makes me wonder if the naming should be reversed. It doesn't seem very useful to have the word Search in the beginning of most of the classes inside the search package, it is redundant and reduces the potential of autocompletion tool since we have to type Search always first when all the classes available inside the search package are search feature related. Wouldn't be better to type Fragment and get all the fragments available inside the search feature?

[luciapayo]

I just realised that the example with Fragment might not be the best since fragments are not package private, but the same idea could be applied to any package private class like Mapper, ViewModel, DataModel, etc...

[ghost]

To be sure that i understand your idea )) You suggest? SearchViewModel -> ViewModelSearch or SearchViewModel -> ViewModel

[luciapayo]

SearchViewModel -> ViewModelSearch

That way if you have several view models in the same feature package you'll see them all listed

[ghost]

Yes but like you mentioned it will not respect the naming convention witch can be important thing for someone :D Also multiple ViewModels inside feature might be a signal of weak feature separation )) If separate features very compact then in most cases we will have 1 View model, 1 DataModel and so on. In this case if ViewModel is package private then we can name it just "ViewModel".

[luciapayo]

There are cases where you can have several ViewModels, the fragment/activity is not the only thing that can have one, actually there is an example of this in this project with SoundItemViewModel and SearchFragmentViewModel, both in search feature package. Also, you can have ViewModels for specific custom views that are complex and you want to control its behavior, I think a clear example in this app could be the PlaybackWavefromView. You can also have a lot of different DataModels if your fragment has a lot of different views representing different stuff.

I know many people is used to the feature + component naming convention and can be weird to change it here but, nevertheless, we should ask why we do the things we do and not just do them because that's the way it has always been.

[ghost]

My idea is bad one because the most used way to open a class is to find it (Ctrl + Shift +N) (at least for me) and it will take more time to choose between all found ViewModels the needed one.

Your approach will help when working inside package but need to calculate if the benefits are really worth to introduce different naming semantics for the same type of classes ))

[peter-tackage]

I had noticed that it was a little bit clumsy prefixing everything in the search feature with "search", although this is definitely preferable to removing the prefix (or suffix) entirely, because having classes with the same name in different packages leads to all types of confusion, regarding of class visibility - which Observable are we using? :-)

I wonder if the existing convention (which comes from the Java standard library - http://www.oracle.com/technetwork/java/codeconventions-135099.html) is driven by English language convention on adjectives. Perhaps defining the class name with the adjective(s) as suffixes reads more naturally for Spanish/French speakers. Personally, for class names, I find that suffix approach a bit awkward to read (and inconsistent with the platform), although I can understand the point about autocomplete, where everything is a "search".

You can also just type, say "SDM" for "SearchDataModel", so it's only a few characters, rather than the full word. This is also got me thinking whether the autocomplete makes any suppositions about class naming structure.

In the end, I'm happy enough with what we have at the moment, but it's an interesting point and thanks for making me think about it.

Now what I'd really like is a better way of naming implementations of interfaces!

[luciapayo]

@peter-tackage Service -> ServiceImpl

You are welcome :trollface:

[ghost]

What about get rid of interfaces where is possible? Most interfaces have only 1 implementation. P.S. I not know how will affect testing ))

[peter-tackage]

Sometimes I feel that wouldn't be the worst idea, @luciapayo.