patternjavascriptMinor
Mapping file data to environment variables
Viewed 0 times
fileenvironmentvariablesmappingdata
Problem
This is a follow-on to my previous question: Enforcing set environment variables
While learning more about JavaScript, node, and the bluemix environment, I have been using the loading of process environment variables as a starting point for understanding how the systems work.
This part of the system checks to see if a 'default' value exists for an environment variable. If there is a default, and the variable is not set, then the variable is set to the default's value. Default values are stored in a file in a pre-defined directory (the same folder as the script file).
After taking in the review suggestions, and some other suggestions from colleagues, I have changed the code mechanism to use a map/filter/process system on the files. This makes the code quite a bit neater.
Note: this code is a file/module in a node.js application deployed in a Bluemix host.
Again I am looking for any further insights in to how the code can be improved, and if any edge cases exist. Performance is not critical, but as I am just learning JavaScript I would appreciate any insights in to any bad practices that should be avoided so that issues are avoided later on.
In particular, I am concerned that the code is not as asynchronous as it could be, though it is a requirement that all the variables are set before the code terminates (nothing asynchronous can be incomplete).
```
/jshint node:true/
/*
* Load various pre-determined environment variables
* (files in this folder with .env extension).
* Only if they have not previously been set in the environment.
*
* This makes the setting of Bluemix style variables quite easy.
*/
var fs = require('fs');
var path = require('path');
var env = /\.env$/;
function isEnv(fileName) {
return fileName.match(env);
}
function processEnv(fileName) {
var key = fileName.replace(env, "");
if (process.env.hasOwnProperty(key)) {
return;
}
var filePath = path.join(__dirname, fileName);
var data = fs.readFileSync(f
While learning more about JavaScript, node, and the bluemix environment, I have been using the loading of process environment variables as a starting point for understanding how the systems work.
This part of the system checks to see if a 'default' value exists for an environment variable. If there is a default, and the variable is not set, then the variable is set to the default's value. Default values are stored in a file in a pre-defined directory (the same folder as the script file).
After taking in the review suggestions, and some other suggestions from colleagues, I have changed the code mechanism to use a map/filter/process system on the files. This makes the code quite a bit neater.
Note: this code is a file/module in a node.js application deployed in a Bluemix host.
Again I am looking for any further insights in to how the code can be improved, and if any edge cases exist. Performance is not critical, but as I am just learning JavaScript I would appreciate any insights in to any bad practices that should be avoided so that issues are avoided later on.
In particular, I am concerned that the code is not as asynchronous as it could be, though it is a requirement that all the variables are set before the code terminates (nothing asynchronous can be incomplete).
```
/jshint node:true/
/*
* Load various pre-determined environment variables
* (files in this folder with .env extension).
* Only if they have not previously been set in the environment.
*
* This makes the setting of Bluemix style variables quite easy.
*/
var fs = require('fs');
var path = require('path');
var env = /\.env$/;
function isEnv(fileName) {
return fileName.match(env);
}
function processEnv(fileName) {
var key = fileName.replace(env, "");
if (process.env.hasOwnProperty(key)) {
return;
}
var filePath = path.join(__dirname, fileName);
var data = fs.readFileSync(f
Solution
This code is very clean and is definitely a clear improvement from your last version.
Your code is easy to understand and follow, now that's it's more broken up (aside from one big block of code).
I recommend storing your regexular expression for locating the extension
The reason is for this:
The
-
Returns
-
Returns
Now, your
Why is this better? Well...
-
The
-
The
That being said, the
Your code is easy to understand and follow, now that's it's more broken up (aside from one big block of code).
I recommend storing your regexular expression for locating the extension
.env like this:var env = new RegExp("\.env$/", "");The reason is for this:
RegExp.test.The
test method of a RegExp object does the following:-
Returns
true if the regexular expression matches the input string.-
Returns
false if the regexular expression does not match the input string.Now, your
isEnv function does this:return env.test(fileName);Why is this better? Well...
-
The
test method of RegExp only has to worry about the regexular expression matching at all.-
The
match method of a string has to worry about the regexular expression matching AND it has to worry about creating and returning an array of all the matches.That being said, the
test method is obviously faster than using match.Code Snippets
var env = new RegExp("\.env$/", "");return env.test(fileName);Context
StackExchange Code Review Q#97859, answer score: 3
Revisions (0)
No revisions yet.