I’ve got a question closely related to this one. I’m cleaning up a colleague’s mess, and I’m afraid that that means trying to work with a language — JavaScript — that I’m almost completely ignorant of.
Basically, we’ve got C code, with a bunch of enums defined in headers, passing data to JavaScript, which uses a bunch of magic numbers in place of those enum values. Any time the enums change, the JS breaks. I want to pull the values from the C header files into the JS, changing the magic numbers to symbols.
Our build process already has a small utility which processes all of the enums in specified C header files into C code consisting of lookup tables of strings, which code is then made part of the main app. This lets us use the literal strings corresponding to those enums in our XML data files… kludgy, but it gets us where we need to be. I think I could do something similar to generate JS code which defines constants having the values of those enums from the C header files.
My question: It would probably be much simpler, and easier to maintain, to simply process every enum in a *.h file than to try to narrow it down to only the ones we actually need for the JS stuff. My guess that if the JS has to include a bunch of constants that it never does anything with, there will be something of a performance hit. How bad is this likely to be? Is it worth the coding hassle to try to keep the resulting generated JS as lean as possible?
Thanks!
There are a few considerations to take into account.
- Even unused constants will take up memory and processing time on the client’s browser. How much of an issue this might be depends on how many of those unused constants you have and how many resources (memory and CPU power) your clients are expected to have.
- Everything you send in JavaScript should be considered to be public knowledge. If you have enumerations that are meant to stay internal in the company, you better make sure that they don’t end up in a JavaScript file.
If your code is already structured in such a way that the enumerations that are relevant for the JavaScript interface are located in header files by themselves with no (or few) unrelated enums, then I would recommend to go the same route you have done for the XML data files: Use a utility in your build process that takes a select number of header files (preferably specified on the command line or in a configuration file) and creates JavaScript files out of them with the enumeration contents.
1
I’ve come up with another solution that I think may work. For all of the .js files that we’ve currently got in a working directory (e.g. “script_dir”), we maintain the original code with meaningful symbols in a source directory (e.g. “script_dir_source”). The build process copies all of the .js files from the source directory to the working directory, then generates a ‘sed’ script from those C header files and runs it on the files in the working directory, converting all of the symbols into their numerical equivalents. There’s no overhead at run time, and as a bonus, the files that the users see are obfuscated because they’re just getting the magic numbers.