While a class usually has the same name as it's contained class - how about the filename of a struct? The below example actually works.
File names and files themselves are completely arbitrary. You can put multiple object type declarations in one file, and they need have nothing to do with the name of the file. (You can also spread out an object type declaration over multiple files, thanks to extensions.) And the names of those types are unrelated to the name of the file.
The reason for giving a file a name that has something to do with its contents is so that you can find those contents; it does not affect the behavior or compilation of the program in any way.
Okay, exceptions:
In Swift, only main.swift has special behavior based on its name - and you don't have a main.swift.
Privacy in Swift is file-based, so you want to separate object type declarations that need to keep things private from each other into separate files.
They usually do but in Swift you honestly can call any file anything you want. I have many different files with not directly related names, some with one class, some with multiple, some with just structs, some with class(es) and structs. The new class function in Xcode will give it a specific name but that was never necessary.
Related
I am writing a static library in Swift that will be reused in multiple projects. The problem is class and struct names I am using are common and can easily conflict with other libraries/frameworks. I don't see any obvious way to create my own namespace in Swift. What's the best way to avoid name collision between classes in multiple libraries/frameworks?
You don't to have to avoid. Just use the name you like. Then when you want to access to your class/struct/protocol..., just use your module name as a namespace.
Example:
import MyModule
let a: MyModule.Result // the Result type defined inside the `MyModule`
let b: Result // Swift's Result type
As others have said, if there is a conflict, you can always fully qualify the symbol name with the module name (See Cong's answer.)
Apple's suggested way to handle this in the days of Objective-C was to use your intials or your company's initials as a prefix for your symbol names. I'm not a big fan of that since it creates ugly names that obscure the underlying meaning.
Using an abbreviated version of the module name/framework name is a little better, and what Apple tends to do, e.g. UIKit views are UIViews, and AFNetworking's connection object might be an AFNConnection.
Others are arguing strongly in the comments that this is no longer needed and no longer recommended. (Like I said, I've never liked it anyway.)
I just created my first custom Swift class and I noticed that it didn't add the class name when I ceated the swift file, in fact the only thing in that file is the import statement for the foundation. If I'm not mistaken Xcode copies the file name when you create Obj-C classes.
Is it a good naming convention to name your custom classes the same as the file name in Swift/iOS?
Yes it is a good practice. If the IDE doesn't do it, do it yourself for the sake of your sanity. I don't want to open a project with tens of classes where the class Person is defined in file1.swift.
Yes, just like in other languages, it is good practice to name the file the same as the class. It avoids confusion and makes it clear.
I have a plist file that contains a top level dictionary and that dictionary contains an array of strings.
I want to test:
That the dictionary is not nil
That the array is not nil
And that the array has at least one valid string object in it
I have these unit tests running great. Very de-coupled. But the problem is I have to make the class functions public in order for Xcode XCTest to be able to test them. These 3 functions are simply helper functions to get the actual data we need.
How do I employ proper visibility on these helper functions while keeping my tests? No one needs to know about these 3 functions, but I want them tested.
There are two solid options for this:
Create a second .h file named something like MyClass_TestHelpers.h where you can declare those methods you need.
Create a category on the class titled something like 'TestHelpers'.
Both do essentially the same thing: declare methods in another .h file. In either case, just include that .h file in the test class. This way the methods are only exposed to your tests.
There are some enum types in my iOS objective-C app that are used in different classes, for them I guess its fine to put them in a constants.h file, but what about others that are not necessarily used in multiple classes? would it be considered a bad practice?
While sapi's answer isn't wrong, here's what I have a tendency to do...
A group of constants that are used across multiple files will go into a file. Let's say all my Foo constants go in FooConstants.h.
Now another group, say the Bar constants, they'll all go in BarConstants.h.
These files will have constants, enums, and protocol definitions in them.
In the files that need the Foo constants only, I'll import FooConstants.h.
In the files that need the Bar constants only, I'll import BarConstants.h.
And depending on the project, I may have just 1 of these files, or I may have 10 or more. Usually I'll have a file called SegueNames.h, where all of my storyboard segue identifiers are created as constants and put in this file so I never misspell a segue name. I'll also usually have DefaultsKeys.h, where I keep the keys to anything I'm putting in NSUserDefaults.
And then I started realizing every now and then, I might have a file that uses 6 of these constants files, so I started creating Constants.h.
Constants.h has nothing in it except importing all the other constants files. This cleans up the top of some of my files.
But at the end of the day, I do still keep the constants organized in their own files with some sort of grouping putting common constants together. And as sapi points out, any constant that is used only in a single file should be defined within that file.
Yes, it is bad practice.
If you place all of your constants, including enums, into the one file, then importing that file becomes necessary whenever you want to reuse part of your code.
A better practice would be to group your constants by function (at whatever level is appropriate for your app), and to include constants used only in a single class in the class file itself or, if you must, in a separate header.
It depends on the context. How well organized are your classes? If it's a bit of a mess, it doesn't hurt to start with an Errors.h/m file where you define your error codes as enums in the .h file and your error domains as NSStrings in the .m file (with corresponding extern NSString * const in your .h file).
If your organization is a bit better, then you've divided your classes into modules and each module has an entry point, where you should be defining these things. The result doesn't change though: Error header for enum values and extern declarations, error implementation for extern assignments.
All my error declaration files look like this:
// ErrorFile.h
typedef enum {
ModuleErrorOne = 1,
ModuleErrorTwo,
ModuleErrorThree
} ModuleError;
extern NSString * const ModuleErrorDomain;
// ErrorFile.m
NSString * const ModuleErrorDomain = #"ModuleErrorDomain";
You can stick it in your pre-compiled header for a compilation speed boost.
EDIT: Thanks for the comments nhgrif and GraniteRobert, they've improved my answer.
Looking in the ASP.NET MVC 2 source code there are several files in the System.Web.Mvc project that have an almost identically named file except for the `1 on the end of the file name.
For example, there is HtmlHelper.cs and HtmlHelper`1.cs. Another example is AjaxHelper.cs and AjaxHelper`1cs.
At first glance, the obvious answer is the `1 files contain the generic versions of their respective non-generic classes.
I'm wondering if there is something more to this naming convention though given that we have other files like ReaderWriterCache`2.cs which contains the ReaderWriterCache file that doesn't inherit from any type of non-generic base class.
Does anyone have a better idea on what the naming convention is used to denote?
The number at the end indicates the number of generic type parameters. So, ReaderWriterCacherequires'2 requires 2 type parameters, TKey and TValue. HtmlHelper'1 only requires 1.
Not sure if this is even relevant, but here's some code snippets from a project:
List<UserAction> myUserActionList;
DataGridTableStyle ts = new DataGridTableStyle();
ts.MappingName = "List`1"; //ts.MappingName = myUserActionList.GetType().Name;
The last line contains a comment which could have replaced that line with no difference in behaviour.