I am working on a rather big Node.JS project with several thousand lines of code. It's not a homepage, but acts more like a configurable general purpose application server. As such it brings some parts which are useful in most projects I do.

The problem is that I easily lose overview in the core modules. So I did a bit of research and came up with an interesting structure based on C++ Header/Code file structures. I want to know if this structure is good in the long run (maintainability, testability, extensibility), how it can be improved and if there is already a (better) "standard" way of doing the structuring I did not find.

The structure has three kinds of files, where xxx is the module name and yyy is the method name.

  • xxx.h.js: The "header" file, which contains the class and method declarations
  • xxx.yyy.c.js: The "code" files, which contain one method each (and possibly local helper functions)
  • index-xxx.js: The glue and main file for the module

I would like to structure all my sub-modules like this and then use a loading-mechanism to load all modules, namespace them and finally use them globally.

Here's an example:


    "name": "Foo",
    "version": "1.0.0",
    "description": "Does something in the core system",
    "author": "Marco Alka",
    "main": "index-foo.js"

// index-foo.js
'use strict';

// return class
module.exports = require('./foo.h.js');

// overwrite definitions with declarations
// this part can and most probably will be done generically by my module loader. I write it down for easier overview.

// foo.h.js
'use strict';

 * Easy-to-read interface/class
 * No obstructive code in my way
module.exports = class Foo {

  constructor() {}

   * Put comments here
  bar() { throw 'Not Implemented'; }

   * More comments for methods
   * See how the method declarations+documentations nicely dominate the file?
  baz() { throw 'Not Implemented'; }

// src/foo.bar.c.js
'use strict';

// include header
var h = require('../foo.h.js');

// implement method Foo::bar
h.prototype.bar = function () {


// src/foo.baz.c.js
'use strict';

// include header
var h = require('../foo.h.js');

// implement method Foo::bar
h.prototype.baz = function () {


Example on how to use the whole thing from within the root folder

'use strict';

// later on a module loader will be used which loads the folder as module instead of the index file directly
var F = require('./index-foo.js');

// make object
var foo = new F();

// call method

Output in console: Foo.bar\n

  • The reason that your question didn't get much attention when you asked it is because it is too broad. Questions like "Am I right?" and "Is this a good approach?" seldom make good questions, because we don't know what your specific criteria is for "right" or "good," which means we have to write a very long answer to cover every positive or negative possibility. Real questions have answers; I suggest you focus your question on a more specific problem. Otherwise, the answer is "yes, if it meets your requirements." Commented Jan 20, 2016 at 15:36
  • See also Are Design Review questions on-topic? Commented Jan 20, 2016 at 15:40
  • The problem is that I easily lose overview in the core modules. -- What does this sentence mean? Commented Jan 20, 2016 at 15:41
  • Incidentally, Googling your question title yielded a number of interesting results, including this one which mentions Dependency Injection, the first thing I thought of when I saw your question. Commented Jan 20, 2016 at 15:53
  • My focus for this question is on how the files interact with each other. Is it a good idea to scatter the code? Is there a better way to divide my big code file into many smaller ones? Will the require-lines in the index-file cause more confusion later on than they bring merit? Google did not yield anything interesting when I searched for how to organize my module with ten thousand lines so that I do not have to constantly use search just to find a method (not the search term I used, but do you get what I am trying to do, now?)
    – Maru
    Commented Jan 20, 2016 at 16:38

1 Answer 1


I'm a newbie and I'm pretty sure this is an opinion-based answer which is really outside the scope of the board. With that, here's my practical experience:

  • There are no implicitly bad ways to structure code, so long as the structure can be described simply.
  • The only thing bad about poor code structure is lack of discipline: if you consistently follow the structure when developing, then you or anyone else editing your code should be able to discern the context quickly.
  • Even if you are the only person on your development team (which is sounds like you are), use Git or some other kind of repository with good robust explanations for what you changed and why.

It's been my experience that code structures are not usually the culprits for making things difficult to manage. It's logical architecture and documentation. If you have a good logical architecture that clearly defines modularity of functionality and you document what you've done, it will be an investment that pays off.

  • Welcome to StackExchange. Your answer is pretty vague, but it definitely confirms me in what I am doing. We are currently two people on the team working with TFS with no quality control or the like. So I really have to do anything I can to keep the codebase clean with a good overview, especially when it's very likely that I will have to introduce it to other people (or maybe even teams) later on. Also working with the code (debugging etc.) has to be efficient since we are such a small team
    – Maru
    Commented Jan 28, 2016 at 10:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.