| const int c = 261; | |
| const int d = 294; | |
| const int e = 329; | |
| const int f = 349; | |
| const int g = 391; | |
| const int gS = 415; | |
| const int a = 440; | |
| const int aS = 455; | |
| const int b = 466; | |
| const int cH = 523; |
| . | |
| ├── public | |
| │ ├── img | |
| │ └── .gitkeep | |
| ├── src | |
| │ ├── coffee | |
| │ │ ├── collections | |
| │ │ ├── models | |
| │ │ ├── routers | |
| │ │ ├── views |
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
Как вы называете переменную, когда нужно сохранить this в замыкании?
Вопрос не праздный, ведь это дело даже не личного вкуса, а, скорее, договоренности.
В коде проекта, над которым я сейчас активно работаю, можно было с равной степенью вероятности
встретить that и self.
Через два года разработки, впрочем, баланс заметно сместился в сторону that.
Но знаете, что? И self, и that, и даже _this с me — это очень хреновые названия.
| /* Rounded arrow button prototype. */ | |
| /* Shitty gradient, I know! */ | |
| .button { | |
| position: relative; | |
| display: inline-block; | |
| padding: 1em 0 1em 1em; | |
| margin: 100px; | |
| font: 20px/1.5 Helvetica, Arial, sans-serif; |
| /** | |
| * Module Dependencies | |
| */ | |
| var debug = require('debug')('lapwing:build'); | |
| var relative = require('path').relative; | |
| var resolve = require('path').resolve; | |
| var extname = require('path').extname; | |
| var uglify = require('gulp-uglify'); | |
| var Batch = require('better-batch'); |
| { | |
| "name": "my-app", | |
| "version": "1.0.0", | |
| "description": "My test app", | |
| "main": "src/js/index.js", | |
| "scripts": { | |
| "jshint:dist": "jshint src/js/*.js", | |
| "jshint": "npm run jshint:dist", | |
| "jscs": "jscs src/*.js", | |
| "browserify": "browserify -s Validating -o ./dist/js/build.js ./lib/index.js", |
| # generate iconfont from svgs | |
| gulp.task 'common:iconfont', -> | |
| gulp.src config.paths.src.common.svg.icons.all | |
| .pipe g.iconfont | |
| fontName: "icons" | |
| appendCodepoints: true | |
| normalize: true | |
| .on 'codepoints', (codepoints) => | |
| codepoints.forEach (glyph, idx, arr) -> | |
| arr[idx].codepoint = glyph.codepoint.toString(16) |
I fell in love with CoffeeScript a couple of years ago. Javascript has always seemed something of an interesting curiosity to me and I was happy to see the meteoric rise of Node.js, but coming from a background of Python I really preferred a cleaner syntax.
In any fast moving community it is inevitable that things will change, and so today we see a big shift toward ES6, the new version of Javascript. It incorporates a handful of the nicer features from CoffeeScript and is usable today through tools like Babel. Here are some of my thoughts and issues on moving away from CoffeeScript in favor of ES6.
While reading I suggest keeping open a tab to Babel's learning ES6 page. The examples there are great.
Holy punctuation, Batman! Say goodbye to your whitespace and hello to parenthesis, curly braces, and semicolons again. Even with the advanced ES6 syntax you'll find yourself writing a lot more punctuatio
