As people who are passionate about writing great code we display "badges" in our code repositories to signal to fellow developers that we set ourselves high standards1 for the code we write, think of them as the software-equivalent of the brand on your jeans or other reliable product.
Help spread the Code Quality Love! ❤️
Please ⭐ this repo and share it with others by re-tweeting:
We use the following badges (listed in order of importance):
-
Continuous Integration -
- "build passing" indicates that the project's tests all pass as expected. If you see that the build for a project is "broken" it means the software does not work as advertised! This is a clear sign that you should not be using it (until it gets fixed!) ... check the repo's issues to see if it's a known problem, if not, report it!
We use Travic-CI for our CI. We wrote a little how-to/tutorial to help you (and your team) get started: https://github.com/dwyl/learn-travis -
Test/Code Coverage -
- coverage is the measure of how much of the code in a project is tested. Anything below 100% coverage means the module/library has potential bugs which are unknown to the authors/users. We avoid using modules with less than 100% coverage and encourage others to question why the authors did not put in the time to test their code... ALL our code is tested. we cannot guarantee every line is "bug-free", (and always welcome people reporting any issues!) however we are meticulous about testing our work and always add regression/edge test cases where bugs are discovered!
-
CodeClimate -
- is the code quality score for the project measured on a number of factors including Complexity/Simplicity, Readability, Maintainability, Repetition and Line-count-per-file . The maximum score is 4.0 and we obviously strive to achieve this level in all our work. https://github.com/dwyl/learn-codeclimate
-
BitHound -
- similar to CodeClimate but has way more detail! and charts progress/regression on a graph which is great for monitoring code quality in teams! see: https://www.bithound.io/features
-
Dependencies -
- knowing your module/project has (and works with) the latest versions of all its dependencies is a good way to signal that any bug-fixes/performance improvements/security patches etc in the component modules/libraries are considered in by the authors. We use https://david-dm.org/ to track our dependencies. david-dm is lovingly maintained by @alanshaw of TableFlip (a fellow dwyler!) and is a great resource for the node.js community!
-
devDependencies -
- your devDependencies are the modules used in testing/building your project. These do not need to be the latest versions because you will typically not install your devDependencies on your production server (so there aren't security vulnerabilities in production of having out-of-date devDependencies...) however, we encourage use of latest devDependencies because it means better stability in the build (fewer bugs in our tools!) and it makes it easier for new people joining the project because when they
npm installthey know everything is the latest version. -
NPM Module Version -
this is a simple convenience to signal to fellow developers which version is the latest for your module. (save them having to look at the package.json) if you want to include one in your readme, go to: http://badge.fury.io/for/js and type in your npm package name.
[](https://travis-ci.org/{ORG-or-USERNAME}/{REPO-NAME})You'll need to setup your project on Travis-CI and write unit tests (preferably TDD!) for this to work ... if you're stuck ask us how!
Setup your repository by adding it on code climate then copy the badge markdown from them!
For more detailed instructions see: https://github.com/dwyl/learn-codeclimate
The new kid on the block for Test Coverage is: https://codecov.io/#features
We love their features especially the fact that they check
coverage for pull requests!
To setup codecov simply add the following lines to your
.travis.yml file:
before_install:
- pip install --user codecov
after_success:
- codecov --file coverage/lcov.info --disable searchAnd remember to output a coverage report in your tests using istanbul,
by adding it to your test script in your package.json
so that travis can send the coverage report to codecov
e.g:
"scripts": {
"test": "./node_modules/.bin/istanbul cover ./node_modules/tape/bin/tape ./test/*.js"
}If you are new to istanbul check out: learn-istanbul
Working example: hits/.travis.yml
Note: you can still use CodeClimate for Coverage if you prefer,
we're excited that there is more choie in the JS testing space!
## Why? [](http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action)
[](http://nodejs.org/download/)
## Contributing [](https://github.com/dwyl/esta/issues)
[](https://gitter.im/dwyl/?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)[](https://gitter.im/dwyl/chat?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
Ever wanted to know how many people have viewed your GitHub Repo?
We did ...
So we wrote a tiny script that counts views! 😮
[](https://github.com/{username||org}/{project-name})Yes, we know that "hits" = "How Idiots Track Success" ... but, in the absence of better analytics, its a fun metric to track 😉
If you need to adapt any of the images or create your own: http://shields.io
We needed High-resolution versions of the coding badges for a presentation about testing so we made PNGs from the SVGs ...
These are in the folders in this repo in case they are useful to someone else.
1Other repositories that do not have these badges are not necessarily "worse" or have "low standards", they simply are not making them explicit .