Aria Templates Forums
hashspace internals JavaScript code style - Printable Version

+- Aria Templates Forums (http://ariatemplates.com/forum)
+-- Forum: Public forums (/forumdisplay.php?fid=3)
+--- Forum: Hashspace (/forumdisplay.php?fid=14)
+--- Thread: hashspace internals JavaScript code style (/showthread.php?tid=168)



hashspace internals JavaScript code style - donk - 22 January 2014 13:34

If got a question regarding the project layout and the JavaScript coding style used for the hashspace internals. Are you following a dedicated style guide for the project like for example the Google JavaScript style guide?

Because I skimmed through the sources and noticed quite a few different "styles" being applied.

For example the file naming is inconsistent: sometimes camelCase, sometimes not. See for example "hsp/compiler/treeWalker.js" vs "hsp/rt/exphandler.js".

Variable naming and function naming seems also to be inconsistent in some areas. Sometimes camelCase, sometimes not. Sometimes abbreviations, sometimes not. Just to list a few examples:

/hsp/transpiler/formatAST.js
module.exports = function (ast, fileContent, options) { //camelCase for variables

/hsp/rt/tnode.js
createAttList : function (attcfg, ehcfg) { // no camelCase for variables and the abbreviations are not very intuitive for newcomers

/hsp/compiler/parser.js
function getBlockList (template) { // camelCase and not abbreviated

I know it is still early stage of development, but especially for newcomers this can be quite irritating and a hurdle for contribution. In my opinion the project should decide on / define a consistent style guide which everyone should adhere to. This would greatly increase the readability and
accessibility of the hashspace source code. What is the general opinion on this?


RE: hashspace internals JavaScript code style - Olaf - 22 January 2014 15:05

I agree that we could come up with a set of coding rules to be followed for new contributors. Up until now, Bertrand was practically the only one committing (thus the abbreviated pre-minified variable names Biggrin) but it makes sense to have more consistency across the code base from all participants, especially at this early stage.

I'll bring up the issue to Github.


RE: hashspace internals JavaScript code style - jakub-g - 24 January 2014 14:41

+1

BTW we've got a number of inconsistencies like this in AT (I'm trying to address them from time to time when I see something but certainly this is one thing to have a solid look at). For instance, some events/functions are named `onfoo`, others `onFoo` etc...


RE: hashspace internals JavaScript code style - Marc Laval - 30 January 2014 10:25

Big +1 here, cryptic variable and function names make it difficult for code readers.


RE: hashspace internals JavaScript code style - Olaf - 30 January 2014 17:47

Issue opened on GH.