这些语法扩充大家是怎么组织代码的呢？

lodash.js/underscore.js 然后require

直接加prototype上，让别人debug比较麻烦。
所以一般是自己写一个util继承lodash，然后扩展util。

如果只是要操作字符串的话，可以使用 underscore.string http://epeli.github.io/underscore.string/

node 项目的话，可以在 app 目录下创建一个 helpers 目录，用来放这些函数（总觉得 node 项目的很多地方都可以直接参考 Ruby on Rails 的做法）

不过还是不太推荐直接扩展原型……

一般自定义的通用模块我会放在lib目录下

> for(var key in "abc"){console.log(key);}
0
1
2

> String.prototype.endsWith = function(suffix) {
return this.indexOf(suffix, this.length - suffix.length) !== -1;
};

> for(var key in "abc"){console.log(key);}
0
1
2
endsWith

直接修改原生对象不是一件好事，如果非要这么做，建议用
Object.defineProperty(String.prototype, {enumerable:false, ...})
并明确 enumerable 为 false. 不然指不定哪些地方就出问题了。

1. 加 prototype 至少要这样加，否则会有 @Mutoo 的问题：

Object.defineProperty(String.prototype, "endsWith", {
value: function(suffix) {
return this.indexOf(suffix, this.length - suffix.length) !== -1;
}
});

而且当你用 for in 而且没写 hasOwnProperty 时，你的编辑器应该给警告（如果没有一定要配置一下）。

2. 这样的修改原生对象的代码可以直接加到程序入口出，这样所有从入口 require 的模块也可以用这些 sugar 了。

3. 至于这样的实现好不好，利不利于 debug 就见仁见智了。underscore vs sugar

Object.defineProperty 只是试用于高级浏览器。
String.prototype.endsWith 基本是没有问题的。forin 的时候判断下hasOwnProperty就ok了。基本 forin 都会判断的。

放的位置么，把这些东西全部收集下放到代码最前面就可以了。

至于上面说的改原型好还是当成一个函数。这个自己的项目无所谓。怎么喜欢怎么来就可以了。多人开发不推荐。至少如果要加的话应该大家统一明确觉得需要加才加。随意污染原型还是会出各种莫名奇妙的bug的。比如举个例子：
比如 程序员1在 Object 上加一个 isArray 方法很常见吧。
然后另一个程序员2写了个 forEach 函数，
function forEach (objOrArray, callback, {isArray: false, context:}) {...}
用最后一个参数的isArray 判断是循环数组还是forin。 最后一个参数可缺损。默认是false。(基本默认都是true。 但是我这边只是举个例子)

那么这个如果缺损的时候 默认就都是true了。 而且这个bug很难debug。如果不知道程序员1有这样的代码的情况下。

@zythum 所以 underscore.js 这些库推荐把工具函数外部实现，而不是直接去修改原生对象。

js 里面一般都不推荐修改 prototype 的，用 underscore.string 试试？

@Mutoo
这个处理 真心见人见智的。 我只是说业务里面不推荐去改原型。 对于类库而言api都是可知的。所以危险不大。
现在处理全部污染原型的。 prototype， mooTools
用原型补全IE等低级浏览器的 avalon
不污染原型的 underscore之类的

还是不要这样做，用现成的库更好，不要忽视最佳实践，都是前人的经验教训。