Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am new to Swift development and wanted to ask a question related to Swift files.
If I am making a project is it a good or general practice to use only one struct or class in one file? Do you need to create a different .swift file for every new struct or class ?
It's common to make a new file per type (struct/class/enum) with the file named for the type, but there are exceptions to the rule. If the type definition is small, and closely related to some other type, then it can be easier to read if it's in the same file with the other type definition - that's quite common with enums. Or if the type is nested in an enclosing type, then it's often written inline. But this is a matter of personal preference.
It's not necessary. But create a different .swift file for every new struct or class help you more easy to maintain source code when your codebase is large
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've been told during a job assignment review, that I used weird filenames in my iOS project.
I've added a picture of my project tree. Could you explain me what's weird about these names or if there are any flaws in the tree structure?
Thanks
"Weirdness" is a subjective term and it isn't one that I would use to give feedback to someone in a review.
There is nothing "weird" about the names you have chosen. Perhaps the interviewer was unable to immediately ascertain what "Launches.swift" contained?
Are you able to ask the reviewer for more information about what they perceived as weird? It would be nice to understand more about their opinion.
In general, the name of a source file best describes the primary
entity that it contains. A file that primarily contains a single type
has the name of that type. A file that extends an existing type with
protocol conformance is named with a combination of the type name and
the protocol name, joined with a plus (+) sign. For more complex
situations, exercise your best judgment.
source: https://google.github.io/swift/#file-names
For example:
MasterViewController -> LibraryMasterViewController
MasterPresenter -> BooksPresenter etc
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm learning Swift and I have a question about data model or the Model folder in Xcode. During a project 'Quiz app' we opened a new swift file in Model folder and started to write some code in it.
What is Data model and why instead of writing all the code just in the ViewController file we need to write a separate one in the model folder?
You could, technically, have all the code for your app in a single file. But it would quickly become really hard to find somethig and keep it readable. Also, when working in bigger teams, having a lot of code in few files results in merge conflicts, which could quickly get out of hand.
It is simply a good practice to keep all your classess in separate files, grouped in folders.
As for what a „data model” is - it’s just a representation of your domain problem in code. These classess will most likely represent data you retrieve from web, or create in app to perform some further operations on them or to use them as input for views to present them to the user.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Is it better to declare an ivar in a class extension?
Or is it only a developer preference?
As the name suggest it is an extension to the functionality of class. You may add extra behavior to the class using extension. Adding member variables or stored properties have quite a bit problems viz:
When it is possible to add data member in extension the original class is not aware of the added data member. This leads to problem of allocation for such members while creating object for such classes.
It could also create problem with initialization and de-initialization of data members as these are not known to original init() or deinit() methods.
Adding data member may alter the very nature of class in terms of its behavior.
Currently you are unable to add instance variables to class extensions. This is true for both swift and Obj-C. See this question: Defining a property in iOS class extension.
If you mean, by adding a iVar to the interface extension:
#interface MyClass(){
MyIvar *ivar
}
well, thats a bit of a matter of choice and convenience. In general you should limit your public interface to a minimal set of properties/methods that allow the user to interact with the class in the way you design/expect. While your code will work fine using either method, exposing more properties/functions can result in more problems as consuming classes may uses properties/functions in ways unplanned for or unexpected.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The question is about structuring in iOS
So I receive a message from a company where I passed a test and they say:
"First of all I want to highlight that they said (developers who took my test) that they really liked how clean your code was. One thing where you could improve is the structuring of classes which wasn't ideal."
I asked about what actually I did wrong or what should I improve. I am not sure that this is the stack question, but maybe some one can point me or suggest some thing how for example you structure you code.
I am asking because clean and structure and what about I care every time, but right now I hear that is not ideal.
So usually I write code with the count of lines no more then 250 - 300. I care about pragma marks that separate code into lifecycle blocks, i care about spaces and etc.
So my code is separated also into "folders" where I store appropriate logic elements like:
View Controllers
Views
Constants
Models
Helpers
XIBs (if any)
Storyboards (if any)
Each of these folders have subfolders that is not a group as well but real folder on hard drive and each folder contain some classes which named with appropriate name the class does.
I understand there are no rights or examples how to structures project, because it depend on the tasks and developers or company style. But if I receive some message like above, so then maybe can someone suggest something where I can read about or what I miss maybe.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Just something I've noticed: when you create new files in XCode that are not a subclass of a controller, there is no #interface in the .m file by default. I'm going to assume that's done intentionally - I'm curious as to why that is
I was thinking that possibly its because they're making the assumption that you're going to want most of your properties to be publicly accessible for parent controllers and the likes?
I've tried researching this to no avail - help me out SO! :D
I think I'd generally be wary of trying to draw any conclusions from Apple's template files - a lot of their sample projects and project templates don't really follow best practices. For example, if you create a project with Core Data, the template has all of the Core Data code within the app delegate - somewhere it really doesn't belong.
On the topic of including an #interface class extension within the .m file - I usually have these in most classes, and keep all properties / methods private unless they definitely need to be visible to another class.