Programming Practices – Storing Metadata in File Names: Pros and Cons

programming practices

I have noticed where I work people are keen on storing information in file names, and parsing the file names.

To me this doesn't seem to be especially good practice. I already see the occasional issues with scripts globbing for a file, and getting the wrong one because another file matches first.We are also discussing how to get around problems with separators for the fields.

Is it considered bad practice or not?

What are other accepted solutions for retrieving files from a file system based on some type of metadata?

Best Answer

Yes I think it's bad practice. It is subject to all sorts of problems - for example length limits, encoding issues and conflicts due to duplicate data.

Better is to use a "master file" (sometimes called manifest or index) that contains metadata and paths to the files. Or something similar in a database, register or whatnot. Or to put the meta data inside the actual files, at the top level of some datastructure contained in the file in for example JSON or XML.

This is somewhat analogous to the concept of putting information, or namespacing keys in key-value stores. I think this is ok as long as you use it only to namespace and do quick lookups - the key components are not there to provide parsable information. If you need that information, duplicate it into the value (file in the above case).

Related Solutions

Php – Is error suppressing bad practice

I think you're doing the right thing by suppressing the error, because you are implementing your own error handling.

It might be easier to consider the equivalent in, say, Java. Suppressing the error using @ is analogous to swallowing an exception. The following code, which is similar to yours, is reasonable:

try {
    db = new MySQLi(dbInfo);
} catch (SQLException connectionFailure) {
    die("Database error");
}

(Well, in Java, you wouldn't want the servlet engine to die, but you get the idea.)

However, this isn't acceptable:

try {
    db = new MySQLi(dbInfo);
} catch (Exception e) {
}

Most PHP error suppression is done carelessly, analogous to the latter example, hence the knee-jerk reaction against your code.

Design – Is it bad practice to reuse method parameters

I think it depends on your coding conventions in your project.

I personally let eclipse automatically add the final keyword to every variable and parameter. This way you see at the first glance if a parameter is reused.

In the project at my job we do not recommend to reuse parameters, but if you just want to call e.g. .trim() or set a default in a null case, we reuse the parameter most of the times, because introducing a new variable is in such cases less readable than the reuse of the parameter.

You should really not reuse a parameter to store a very different content because the name would no longer refer to its content. But this is true for every reassigment of a variable and not restricted to parameters.

So get together with your team and formulate coding conventions which cover this matter.

Best Answer

Related Solutions

Php – Is error suppressing bad practice

Design – Is it bad practice to reuse method parameters

Related Topic