2

I'm trying to find a good name for a library where I can put in all non-UI related code that I want to share between iOS apps (networking, filesystem, logic, algorithms, data structures). Names that I don't like too much:

  • Model
  • Backend
  • NonUI
  • Core

Suggestions?

  • 5
    What is the opposite of a Dog? The only logical consistent answer is NonUI. – Stephen C Jun 19 '16 at 22:56
  • 4
    I think the problem here is trying to put all non-UI into a single bucket... why put networking and data structures into the same category? – HorusKol Jun 20 '16 at 1:51
  • 2
    Application logic is one phrase i've seen for it. You can also subdivide it further to include Business logic and Backends. – Cort Ammon Jun 20 '16 at 3:21
  • Try to use Repository maybe :) Application --> Repository then (networking, data structures etc..) – sebastian Jun 20 '16 at 8:56
  • 4
    You're going about this wrong. Name libraries and namespaces after what they do, not what they are. – RubberDuck Jun 20 '16 at 9:11
8

a library where I can put in all non-UI related code that I want to share between iOS apps (networking, filesystem, logic, algorithms, data structures)

Don't you think it's a really bad idea?

The purpose of (1) naming things and (2) having libraries is to make it easier to find things. By putting unrelated stuff in the same library, you go against this purpose. What's the point in having a library in the first place, and in finding a good name for it? If your colleague asks you: “Where do we have the ETL code?” and your answer is: “Look in the HugeLibraryForEverything library”, does the name actually matter?

If you really want to have one and BigMess isn't an option (although it's quite representative), Common would seem explicit enough, since the purpose is to share code among applications. However, I would strongly recommend to have at least some sort of code organization, and to have specific libraries for specific purposes. That networking stuff can go to YourCompany.Networking, and YourCompany.IO will contain the file system stuff. As for the logic, algorithms and data structures, they would find themselves where they belong to, accordingly to what they actually do, instead of being put together just because they are data structures or algorithms. Think about it, why would a stream compression algorithm be in the same library as the sorting algorithm?

Once you have a clear structure, finding proper names for the libraries should be a bit less difficult. I won't assert that it's easy, but at least, you wouldn't be in a situation where you search for a name of a bunch of things which have the only common point of not being something else.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.