felixge / node-style-guide
A guide for styling your node.js / JavaScript code. Fork & adjust to your taste.
AI Architecture Analysis
This repository is indexed by RepoMind. By analyzing felixge/node-style-guide in our AI interface, you can instantly generate complete architecture diagrams, visualize control flows, and perform automated security audits across the entire codebase.
Our Agentic Context Augmented Generation (Agentic CAG) engine loads full source files into context on-demand, avoiding the fragmentation of traditional RAG systems. Ask questions about the architecture, dependencies, or specific features to see it in action.
Repository Overview (README excerpt)
Crawler viewNode.js Style Guide This is a guide for writing consistent and aesthetically pleasing node.js code. It is inspired by what is popular within the community, and flavored with some personal opinions. There is a .jshintrc which enforces these rules as closely as possible. You can either use that and adjust it, or use this script to make your own. This guide was created by Felix Geisendörfer and is licensed under the CC BY-SA 3.0 license. You are encouraged to fork this repository and make adjustments according to your preferences. Table of contents Formatting • 2 Spaces for indentation • Newlines • No trailing whitespace • Use Semicolons • 80 characters per line • Use single quotes • Opening braces go on the same line • Declare one variable per var statement Naming Conventions • Use lowerCamelCase for variables, properties and function names • Use UpperCamelCase for class names • Use UPPERCASE for Constants Variables • Object / Array creation Conditionals • Use the === operator • Use multi-line ternary operator • Use descriptive conditions Functions • Write small functions • Return early from functions • Name your closures • No nested closures • Method chaining Comments • Use slashes for comments Miscellaneous • Object.freeze, Object.preventExtensions, Object.seal, with, eval • Requires At Top • Getters and setters • Do not extend built-in prototypes Formatting You may want to use editorconfig.org to enforce the formatting settings in your editor. Use the Node.js Style Guide .editorconfig file to have indentation, newslines and whitespace behavior automatically set to the rules set up below. 2 Spaces for indentation Use 2 spaces for indenting your code and swear an oath to never mix tabs and spaces - a special kind of hell is awaiting you otherwise. Newlines Use UNIX-style newlines ( ), and a newline character as the last character of a file. Windows-style newlines ( ) are forbidden inside any repository. No trailing whitespace Just like you brush your teeth after every meal, you clean up any trailing whitespace in your JS files before committing. Otherwise the rotten smell of careless neglect will eventually drive away contributors and/or co-workers. Use Semicolons According to [scientific research][hnsemicolons], the usage of semicolons is a core value of our community. Consider the points of [the opposition][], but be a traditionalist when it comes to abusing error correction mechanisms for cheap syntactic pleasures. [the opposition]: http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding [hnsemicolons]: http://news.ycombinator.com/item?id=1547647 80 characters per line Limit your lines to 80 characters. Yes, screens have gotten much bigger over the last few years, but your brain has not. Use the additional room for split screen, your editor supports that, right? Use single quotes Use single quotes, unless you are writing JSON. *Right:* *Wrong:* Opening braces go on the same line Your opening braces go on the same line as the statement. *Right:* *Wrong:* Also, notice the use of whitespace before and after the condition statement. Declare one variable per var statement Declare one variable per var statement, it makes it easier to re-order the lines. However, ignore [Crockford][crockfordconvention] when it comes to declaring variables deeper inside a function, just put the declarations wherever they make sense. *Right:* *Wrong:* [crockfordconvention]: http://javascript.crockford.com/code.html Naming Conventions Use lowerCamelCase for variables, properties and function names Variables, properties and function names should use . They should also be descriptive. Single character variables and uncommon abbreviations should generally be avoided. *Right:* *Wrong:* Use UpperCamelCase for class names Class names should be capitalized using . *Right:* *Wrong:* Use UPPERCASE for Constants Constants should be declared as regular variables or static class properties, using all uppercase letters. *Right:* *Wrong:* [const]: https://developer.mozilla.org/en/JavaScript/Reference/Statements/const Variables Object / Array creation Use trailing commas and put *short* declarations on a single line. Only quote keys when your interpreter complains: *Right:* *Wrong:* Conditionals Use the === operator Programming is not about remembering [stupid rules][comparisonoperators]. Use the triple equality operator as it will work just as expected. *Right:* *Wrong:* [comparisonoperators]: https://developer.mozilla.org/en/JavaScript/Reference/Operators/Comparison_Operators Use multi-line ternary operator The ternary operator should not be used on a single line. Split it up into multiple lines instead. *Right:* *Wrong:* Use descriptive conditions Any non-trivial conditions should be assigned to a descriptively named variable or function: *Right:* *Wrong:* Functions Write small functions Keep your functions short. A good function fits on a slide that the people in the last row of a big room can comfortably read. So don't count on them having perfect vision and limit yourself to ~15 lines of code per function. Return early from functions To avoid deep nesting of if-statements, always return a function's value as early as possible. *Right:* *Wrong:* Or for this particular example it may also be fine to shorten things even further: Name your closures Feel free to give your closures a name. It shows that you care about them, and will produce better stack traces, heap and cpu profiles. *Right:* *Wrong:* No nested closures Use closures, but don't nest them. Otherwise your code will become a mess. *Right:* *Wrong:* Method chaining One method per line should be used if you want to chain methods. You should also indent these methods so it's easier to tell they are part of the same chain. *Right:* *Wrong:* Comments Use slashes for comments Use slashes for both single line and multi line comments. Try to write comme…