Custom convenience functions/methods

Question

Convenience functions are functions that perform a specific task, independant of the program, code or whatever that called it.

Here's an example in PHP:

function currentDateTime(){
  list($micro, $Unixtime) = explode(" ",microtime());
  $sec= $micro + date("s", $Unixtime);
  $sec = mb_ereg_replace(sprintf('%d', $sec), "", ($micro + date("s", $Unixtime)));
  return date("Y-m-d H:i:s", $Unixtime).$sec;
}

This function does one thing only: return a string that represents the DateTime of the moment if was called, ready to be inserted into any database, no matter which PHP file called it.

I wonder, are there any reasons not to keep a bunch of "convenience functions" in a file(or multiple files, based on subject), for use in every project you'll ever work on?

Mind you all, I'm a beginning programmer. I'm not really up to speed to what most people do, but I'm thinking it's handy to keep such a file for future reference and ease of development.

But what should I be mindfull of? Are there any standard? Or do you simply re-invent the wheel everytime you get a new project?

Answer 1

Many people do something similar. This is certainly okay for more complex functions that you will be using often. Keep in mind though that most frameworks often have built-in functions for this type of stuff (.NET has a class for everything), and you may just not be looking hard enough. Never duplicate the frameworks.

Answer 2

Theres nothing wrong with a library of utility functions (if you actually use them).

They do, however, create unnecessary additional overhead if they are referenced in pages that do not use them. For use in PHP, unless you are using an opcode cache, I would simply cut and paste them in when you need them, as including large libraries of unused utility functions (or autoloading them for that matter) is inefficient.

Answer 3

First of all, as Zifre mentioned, don't reinvent the wheel. Comb through the API to make sure the functionality doesn't already exist. If it does, and not it's in an experimental package (one which language developers don't guarantee from one version to another), use it. If you can find third-party coders who have a solution, and you're not violating any license agreements or their conditions of use, try to leverage their code (it doesn't always work). If you simply cannot find what you're looking for (or it's small enough to justify not spending time to research it), move on to writing it yourself.

Second, try to organize your libraries logically so they can be leveraged and delivered as a "component" in other applications. I'm not versed in PHP, but Java libraries can be built into a jar file; these can be included in other program's classpath, allowing them to also access this functionality. Depending your development environment, you will likely have an option to build projects using this set of libraries as an "external" reference, allowing you to keep and maintain them in a single location. The key concept here is keeping the location of your libraries in one place, and allowing other applications to leverage them as needed.

Third, avoid the copy/paste methodology as much as is humanly possible. A single bug in your library will suddenly need fixed in multiple locations, and any attempt at extending the functionality will have to take into account every project which leverages it. Most experienced developers can give you instances of where copy & paste bit them severely and caused a world of issues in the long term. It's not a habit you want to get into.

If there's a concern (as Matt pointed out) about autoloading large libraries in a PHP application, try to break the libraries down even further so only those necessary parts get included. It might take more work in the short term, but if you take into account the future of your code, it's well worth it.