Should I Keep Extensions in Their Own "Extensions" File

Should I keep extensions in their own Extensions file?

I think this is largely a matter of style rather than efficiency. That said, yes you should put them in their own file. That way if you want to reuse them between projects, you can simply drag and drop them into a new project.

In general, it is best to keep your files as small and modular as possible in order to keep things simple. If a piece of functionality doesn't specifically pertain to that file or viewcontroller then I think you should break it into its own file.

Should I create a new extension for an xml file?

Yes. Create a file with a different extension.

The fact that your model uses XML is an implementation detail. The fact that most other file formats use a proprietary binary format doesn't mean that they all have to be called filename.bin, so why should all XML files need to be called filename.xml?

Yeah, sure, it might be nice to double-click the file and have it loaded into an XML-aware text editor. But surely it's nicer to be able to double-click on (for example) a .csproj file (which is XML) and have it load into Visual Studio?

Does file extensions matter for browsers?

No, what matters is the Content-Type header, which gets served in the HTTP response.

Rules for file extensions?

You can use any file extension you want (or none at all). Using standard extensions that reflect the actual type of the file just makes things more convenient. On Windows, file extensions control stuff like how the files are displayed in Windows Explorer and what happens when you double click on it.

What's the best practice for naming Swift files that add extensions to existing objects?

Most examples I have seen mimic the Objective-C approach. The example extension above would be:

String+UTF8Data.swift

The advantages are that the naming convention makes it easy to understand that it is an extension, and which Class is being extended.

The problem with using Extensions.swift or even StringExtensions.swift is that it's not possible to infer the purpose of the file by its name without looking at its contents.

Using xxxable.swift approach as used by Java works okay for protocols or extensions that only define methods. But again, the example above defines an attribute so that UTF8Dataable.swift doesn't make much grammatical sense.

Should I ever use the .html5 file extension?

File extensions are just a small data structure. A file is named, and the name can contain dots in it. By convention, programs can split the name at the last dot, take what's to the right, and do something, including nothing.

For example, a file manager can display icons from its database of extension-to-icon relations, if the authors of that file manager took their time to code that.

An operating system can keep a database of extensions and open a file in a corresponding program afer, say, a double click.

Extensions can be ignored, used and abused. For example, you can pretty easily instruct your Windows to open all .exe files with Adobe Acrobat Reader. After that, you'll have to take another internet-enabled device and google how to fix the outcome. The fix will be just an instruction in the Windows registry.

Or, you can setup your webserver to process .html files with a PHP interpreter, which can seem mind-blowing at first glance.

Should I ever use the .html5 file extension?
You should not. But you may, if you want. You may use .html6 as well.

Is the .html5 file extension backwards compatible?
There is no such thing as file extension backwards compatibility. Think of widespread support instead — has it been embraced widely so that you can send it to your grandma via email, and her double click opens anything except «How would you like to open this file?» dialog? (No, it hasn't)

You can always rename your file using another extension in case of bad happenings.

creating own file extension

If it's character data, use Reader/Writer. If it's binary data, use InputStream/OutputStream. That's it. They are available in several flavors, like BufferdReader which eases reading a text file line by line and so on.

They're part of the Java IO API. Start learning it here: Java IO tutorial.

By the way, Java at its own really doesn't care about the file extension or format. It's the code logic which you need to write to handle each character or byte of the file according to some file format specification (which you in turn have to writeup first if you'd like to invent one yourself).

C: Saving specified files with unique extensions

The only way to make the content of a document unreadable by another software is to apply some sort of transformation on it (cryptography) that could be decoded only by your software, or by a equivalent software that uses the same crypto algorithm as long you have a "key".

The file extension is just a hint to the file manager so it can open a software associated by it, but nothing stops to either manually choose the software or to attempt to open the file directly in the application.

If do you want to train a little, you can try to implement a notepad that saves the file with a ROT13 algorithm.

How to decide on document file extension?

• How important is it nowadays to stick to 3 characters?

It's not unless you have to support older operating systems. All current OSes handle >3 char file extensions without any problems. Think of .html, .config, .resx, and I'm sure there are more.

• Where can you check how much this file extension is already used?

check out FileExt.

• Do I really need to use a file-specific extension? My save
  format is gzip'ed XML, so I could name
  it .xml.gz, but I fear it would
  confuse beginning users (i.e. when you
  see it, it does not immediately "ring
  a bell").

Remember that windows (and windows users) associate files with applications by extension, so using something too generic like .xml.gz may cause problems. You are probably better coming up with something that is more specific to your file type or application. Users don't care weather your format is gzipped xml internally, they care about what is in the file. Think about abstraction layers, your users will think of it as a file containing chemistry info not gzipped xml, so .chem is far more appropriate than .xml.gz

Some suggestions of things to thing about:

1. Obviously, don't clash with anything big - Don't use .doc, .xls, .exe, etc.

2. Don't clash with anything common in your industry domain that your user demographic is likely to have installed. For example, if you are writing a programming tool, don't use .cs or .cpp. You probably know your domain best, so write a list of all the apps you and your users are likely to have installed, and any of their competitors and avoid them.

3. Make sure your app includes the options to register and unregister the extension. don't just automatically do it in the installation, make sure it's an option.

4. Remember unix/linux and Mac are case sensitive, so consider sticking to always all lower case by default.

5. Remember CD/DVD file naming rules are stricter, so don't use non alpha numeric characters.

6. Finally, remember that most non-tech users are going to have file extensions turned off, so don't stress about it too much.

There is more info here.

Wikipedia has lists of files extensions here (by type) and here (alphabetical), and also some general information

---

Related Topics