jmfayard10/14/2019, 4:53 PM
wasyl10/14/2019, 4:59 PM
, StringExtensions.kt` etc. It’s not bad, not great either, as some of those files only have one extension. I suppose I’d group by functionality but I don’t think I had a case when I though that’d be preferable. Interested to hear what others do though, too
GarouDan10/14/2019, 4:59 PM
. And if I have too much extensions I would replicate the package of the function inside of my project with something like:
Marko Mitic10/14/2019, 5:02 PM
jmfayard10/14/2019, 5:07 PM
Casey Brooks10/14/2019, 5:07 PM
file in the package closest to their common usage. No special grouping by receiver or anything here, and intentionally placed to indicate limited usage. For globally-applicable extensions, custom DSLs over existing APIs, things like that, I will put them under an
package just under the root package. And within there I will group extensions by feature, trying to keep related extensions close together even if they have differing receivers.
somewhere in the filename, just to emphasize what’s in there. My extensions tend to just be wrappers around existing APIs, rather than defining entirely new APIs/features themselves, so I prefer to not name them as if they are a feature.
), and then provide extensions to that API in a separate extensions file (`com.root.package.extensions.ListExtensions.kt`_. Helps me to keep straight the internal implementations vs the usage of its API, to make sure each isn’t doing too much work (SRP)
Pablichjenkov10/14/2019, 5:19 PM
louiscad10/14/2019, 9:55 PM
when they bundle non trivial libraries. Then, I name the subpackages after the packages of the types they are extending, and name the files after the name of the type they are targeting, or after what's inside the file. Sometimes, I put extensions directly in the module that needs it (not in the extensions module), but still follow the same set of guidelines for the package and file name.
gildor10/15/2019, 2:05 AM
, it make it harder to navigate across the project - Do not group by receiver type, only if it’s super global extensions that provide some generic features for this type (like stdlib File/Collection extensions) - If extension is generic and belongs to some interface/class (so I don’t want to pollute API of this interface/class with it), keep in a file with this type - I do not create modules with name “extensions” and less and less use this for file, because sometimes I have also some utilities functions (not extensions) in file/module, so name become misleading. So use
for files or utils modules
jmfayard10/15/2019, 5:23 AM