Post Reply 
Author hashspace internals JavaScript code style
donk
Member

Find all posts by this user
Quote this message in a reply
Default  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?
Olaf
Administrator

Find all posts by this user
Quote this message in a reply
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.
jakub-g
AT core team member

Find all posts by this user
Quote this message in a reply
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...

http://jakub-g.github.io/
Marc Laval
AT core team member

Find all posts by this user
Quote this message in a reply
30 January 2014 10:25
Big +1 here, cryptic variable and function names make it difficult for code readers.
Olaf
Administrator

Find all posts by this user
Quote this message in a reply
Default  30 January 2014 17:47
Issue opened on GH.
Post Reply