如何写出优美的 JavaScript 代码？
我是一名前端开发工程师，主要写 JavaScript，有大概两年经验。最近在写一些页面上的模块，发现自己在构思的时候总是很清晰，但是写着写着感觉代码越来越乱，看起来就像一坨屎，而我又有点儿代码洁癖，看着越来越乱的代码就不想进行下去。请问怎么办呢？&br&&br&如下，我截取我部分代码，看起来真的很乱：&br&&img data-rawheight=&718& data-rawwidth=&588& src=&/c991f8e9c927d5f97dd1de24e6f08f8e_b.jpg& class=&origin_image zh-lightbox-thumb& width=&588& data-original=&/c991f8e9c927d5f97dd1de24e6f08f8e_r.jpg&&&br&/*----------------------------------华丽的分割线-----------------------------------------------------------------*/&br&以下两种代码格式，哪种写起来比较好？&br&&b&图1&img src=&/0ba75fe0ec0afae825be8_b.jpg& data-rawwidth=&859& data-rawheight=&551& class=&origin_image zh-lightbox-thumb& width=&859& data-original=&/0ba75fe0ec0afae825be8_r.jpg&&&br&&/b&&br&&b&图2&/b&&br&&img src=&/cd_b.jpg& data-rawwidth=&829& data-rawheight=&637& class=&origin_image zh-lightbox-thumb& width=&829& data-original=&/cd_r.jpg&&&br&&br&&b&说明：我一般写其他代码格式大括号都是上下在一列的 图2所示，在学JS的时候，老师让我用 图1 的格式去写，也没有理由。我想问一下各位，在工作种，一般都用哪种格式？这两种有啥讲究没？工作中一般都用哪种格式？&/b&
我是一名前端开发工程师，主要写 JavaScript，有大概两年经验。最近在写一些页面上的模块，发现自己在构思的时候总是很清晰，但是写着写着感觉代码越来越乱，看起来就像一坨屎，而我又有点儿代码洁癖，看着越来越乱的代码就不想进行下去。请问怎么办呢？如下，我截取我部分代码，看起来真的很乱：…
按投票排序
我觉得写好代码和作文章差不多，无外乎：工整、优雅、拒绝重复、惜字如金。几个小建议：态度对代码有感情，每一行都应该尽心尽力，并且还要有把所有代码扔垃圾篓之后再重写两遍的冲动——一旦有了这种冲动之后，什么都挡不住你，连吃喝拉撒时，问题都会浮现到你脑子里，你就会不由自主地解决它们……能对自己的代码提出怀疑本身就是一件了不起的事！加油！少写代码提前设计能有助于少写代码，增强全局感。而代码写得少还能防止失控——感觉不对时就应该停下来，腾出时间来思考，为什么会偏离最先的想法。所有符号各就各位第一眼的就是空格太少，我推荐三个工具： 可以给你的代码格式化，记得用 diff 工具对照一下，格式化前后的区别；SublimeLinter 可以动态地在编写时给出 JSHint 提示（出错行高亮）；Grunt 可以在文件变更时给出 JSHint 检验（声音以及桌面通知）；一旦把 lint 校验做为提交代码的必要过程，排版就会有本质的提高。遵行惯用法注释符号 `//` 后应该空一格；防止变量提升，应先声明后使用（JSHint 会提醒出 `_height` 存在变量提升以及定义后未使用的错误）；不应该使用硬编码，并且重复几次（ ID 后缀名可以定义到常量里，用大写字母）；不应该有两个配置属性，含义不明（this.opts 和 this._options）；若两次以上引用同一对象的属性，应该定义到局部变量再引用（var options = this._options）；不应该同时使用两种属性命名风格（colModel 和 table_body）；局部变量名应该尽可能短，而方法名应该尽可能完整（不应该同时即有 fromatTpl 又有 parseTemplate）；局部变量名不需要用下划线开头，仅对象私有属性和私有方法有此必要；变量名不需要带类型属性（_thdoms 叫 ths 就好）；使用 JavaScript 时，for 循环基本可以避免（比如 jQuery 有 $.each, $.map，$.filter, $.grep 等等高阶函数可用）；jQuery 对象名习惯以 $ 开头，以便区分 DOM 对象；jQuery 查询应尽量使用 context （如 this.$table = $('table', this.$element) ）；jQuery DOM 操作和原生 DOM 操作不应该混用（已经使用 jQuery 的情况，就应该坚持使用 jQuery 来操作 DOM，避免丑陋的原生操作）；DOM 元素构造出来，也不应该再到文档中查询一遍了（图上的构造太复杂，一眼真看不懂）；Code Review把程序写正确还只是跨出了第一步。把代码交给你的同事和朋友 review，这是学习经验、共同提高 最快的办法。
每个人心目中对代码美的偏好是不同的，有的人觉得浏览器运行效率最高的代码是最优美的，有的人觉的用最少的字符写出来的代码最优美，还有人觉得有大量注释的代码美，还有觉得易读懂的代码才美，甚至有人觉得用语言特性hack出来的代码最拉风......关于“什么样的js代码才是好的代码”，这个问题我持续思考了两年，最后，个人比较偏好认为优美的好代码最重要应该是：易懂易维护写代码的时候我不停的拷问自己：写的这行代码一年后的我能一眼就看明白吗？一年后的我看到这段代码能知道写的是什么，解决思路是怎样的吗？一年后的我对整篇代码的组织架构能清晰明了不？如果这三个问题的有一个答案不太明确，那么就不遗余力的重写........一段好的代码，应该在只读过一至两遍就能明白代码大体是在干嘛，思路是怎样的，如果看完后有一种“层次清晰、一气呵成”的感觉，那么这段代码就应该是优美的了.....一时兴起把lz的一段代码按我的理解改写了一下，各位随意拍砖，不甚感激.....其实不用太在乎短引用的，多写点啰嗦点都不要紧，能被顺畅阅读就行...其实不用太在乎短引用的，多写点啰嗦点都不要紧，能被顺畅阅读就行...个人觉得写代码跟写作文有点像，一件事一件事叙述完后空一行分段落，用词要准确不能有歧义，_getTmpl估计应该是个html的字符串我改成了tmplTableBody，谁的什么。然后_parseTemplateToElement 把什么做什么与谁.......好的文章都是一个字一个词，一句句反复改出来的，每段代码也不会是一次就能写到最好的，也是一个变量名一个函数名，一行一行重构出来的.........另外觉得时不时读读别人的文章，会有很多的启发，而且坚定地认为一种语言如果无法写好，换任何一种也会是一样滴...........
楼主似乎在进行大量的直接DOM操作，这种程序代码一般怎么也优雅不了。不妨换换思路，用用类似angular这种框架，学习学习functional programming，从而让代码更清晰凝练。PS：推荐看看 ，虽然是讲coffescript的，但涉及了很多FP的思想，就算不用coffee也能收益。当然我估计你会爱上coffee的。
用coffee script，如果可以的话（虽然我觉得不会有什么情况是不可以的，coffee这么简单），虽然这个东西本身是为ruby和rails存在的，而你用的windows上ruby完全是废的，不过coffeescript可以用js编译，所以在win上也是应该没问题的（吧？win上node.js应该是可以用的吧，如果node.js都不行，直接用浏览器就能编译了），虽然比linux，mac上可能麻烦一点点我所知道的的唯一解，js本身就这么蛋疼，你再怎么想优美它格式上就乱翻了，无数蛋疼的括号和function一下子就看不懂了，你只要研究一下coffee，代码真的就优美了ps：你为啥不用jquery？自己写这么多。。。。。。
语言本身的问题，再怎么写也不可能优美。看着大段的JS代码就想吐。。。
都行 都能看懂
去github研究那些大牛的代码是怎么写的人生苦短, 试试coffee
代码风格及排版虽然任何一种语言没有规定的风格约定，但也总有一些不成文且喜闻乐见的习俗。以你的代码为例，给一下几个风格上的建议：每个 function 之间多一空行，是的，除去注释外再多一空行；适当加空格，比如 if 和后面的括号之间的空格、小括号和花括号之间的空格、冒号和 function 之间的空格等等；风格上保持一致，你的代码里面有的地方 + 号和运算数之间有空格，有的则没有；少用下划线开头的变量命名；一段代码里，var 语句可以合并在一起；暂时不会再修改的 function 或 object，先用编辑器折叠起来，看上去也会整洁很多；黑色背景的 Editor 风格不错，不过关键字、注释、运算符等颜色上可以再调整，主要是为了防止审美疲劳，换个色调换个心情；使用成熟的 JavaScript 库如果没看错的话，你可能是使用了 jQuery 吧（至少也有一个类似 Sizzle 或更简单的解析器，证据在倒数第十行左右）。所以，就尽可能避免使用原生的 JavaScript DOM 操作。jQuery 的 $ 符号，以 CSS Selector 风格统一取代了各种 getElement(s)ByXxx 的接口，并且扩展性非常强，是很多设计模式思想的综合运用。当然原生 DOM 也有自己的优势（主要是执行效率），但是大部分时候，在开发效率、代码质量、执行效率的 tradeoff 中，jQuery 还是最佳选择。此外也推荐下 JavaScript MVC 库、jQuery UI 库等等。代码整理构思清楚，再写代码，你已经做到了。但是，谁能保证代码是一成不变、一劳永逸的呢？所以，「重构」的时候，除非是时间紧迫，永远不要松懈代码质量。
我也比较年轻，和问者一样。说一下我的看法，可能可以帮助到你。首先，代码可读性不强归根到底是规划问题，这就涉及到架构层面了。一个架构好的产品，当你要新增功能或者改BUG时，你无需思考和查找，就知道你要改和加的代码放在哪里如果没有特别多的架构经验，系统又比较庞大，可以参考MVC的架构模型，可以参考CMD的思想做模块依赖管理。当然，对于本问，上面都是废话------分割线-------下面讲这个代码本身1，一个函数体内的变量声明应该只是用一个var，并且写在首行，如：var a....var b....要改成var a,b..........2，保持框架习惯的一致性楼主貌似有使用$的选择器，按id选择使用了 $('#‘+id)，那么，按标签名选择也应该使用它 $(tagName)，而不是写getElementsByTagName3，对各个非取值器方法使用链式调用在设计时，对于非取值器方法，应该返回this本身，方便链式调用诸如这样：this.method1().method2().method3().....就可以避免这样的代码：this.method1()this.method2()this.method3()4，使用导入和到处的思想及闭包管理私有方法，而不是使用"_"开头使用一个匿名函数作为闭包，导入和导出的示例;(function(w,f,b,e){code...e.abc = ... // abc将被导出到外部的export})(window,foo,bar,export) // 导入的外部变量写在这里5，要干活了 ，先写这么多，欢迎讨论，共同进步
最近做了一个比较复杂的电商购物车, 原来的版本很慢, 由于购物车逻辑异常复杂,满减,满换购,满赠品, 限时特价, 删除后恢复, 等等.
我觉得这种复杂的东西不用流行的前端框架很难做好, 使用jQuery插来插去一会就乱套了. 强烈建议使用了backbone来做, 而且只用到了model, view, 不用router. 使用model的好处就是理清数据模型,
view的好处是可以把显示部分模块化,
并且限制变量和事件的作用范围.
并引入模板. 把所有的提示信息都一次性放到模板里, 而不是在js里面插来插去.
并使用数据绑定 插件, 更改数据都是自动更新页面,而不需要jQuery再去操作.
这样使用了backbone后 想弄乱都不容易.
backbone也有小问题,例如view必须有根节点, 需要把页面拆分成模块, 适合做复杂的应用,
如果是表单,或文章内容页面 没必要用backbone编辑器推荐webstorm, js各种库的提示,git集成,
错误提示. 太好用了===========
====最经在研究angular js , 如果backbone 是1D , angular 就是3D Angularjs 思想是3D, 就是 Data-binding, Directive, Dependency Injection .
其他框架只是2D,或1D. Backbone 是解决mvc,为了更好的组织代码, knockoutJs
主要MVVM和Data-binding,加少了代码. 而angularJs
是从前端实用者出发更简单更好更快的写出复杂的SPA,不仅有Data-binding, 还有 Directive, DI.双向的 Data-binding 解决了繁多的dom中数据读取与写入的问题. Directive 解决了Dom各种奇葩的问题,例如操作样式, 循环, 事件. 通过以上2D 确保做到在js文件中 没有任何操作Dom的代码, $ jQuery 基本抛弃. 这个思想非常重要,节省很多时间和维护成本.
尤其是Directive 自定义的指令
例如ng-class 真正解决了仅仅使用html 属性标签就能完成样式的控制. 实际上,仅通过Data-binding 数据绑定根本做不到操作css样式, 但有了Directive 前端开发人员的贴心工具, 终于和dom说再见了.Dependency Injection 解决了model 数据 在多个controller 控制器之间的传值和同步问题. 多个controller 控制器之间的传值是任何语言都有问题, 但我觉得DI是解决这个问题的很好的方法. Backbone 提供了一种良好的代码结构, model , view, router, 但没有节省代码,
Angularjs的出现是提供了一整套节省代码的方案, 但组织代码只能靠最佳实践.
也许Angularjs 未来还会发展的更好,组织代码整理出好的方案, 完全解决了 html 与 js, jsmodel与 js viewmodel文件的组织.最后说一下, 感觉如果只用jQuery 这种, 基本是指哪打哪的操作 DOM,基本不可能写出好代码, 因为很多功能有连动的时候,例如触摸某个点击事件改一个数值,或改一个样式. 同样的情况其他点击事件也是同样的操作, 但根本无法知道有哪些关联,
最好的方法还是 只要更改了这个数值或样式都有一个对应的状态属性, 更改时只修改状态而不是直接操作dom. 那么就是angular的思想.
废话不多说了，风格上的问题直接参考 ： 足以。
大道理大家讲了很多，我讲一下这块代码的具体问题吧。第一，代码中逻辑没有分块，没有空行，没有注释，看起来很累，建议对代码进行分块，比如将变量集中在头部定义，然后处理一些赋值，最后执行一些其它的函数。具体到这个例子，有很多不恰当的地方，比如可以先var _然后在条件分支中进行赋值，比如在一堆赋值语句中间夹杂了一个parseTemplate。第二，“_”用得太多，this._var这个可以理解，因为要区分是否私有变量，但是var _height这个完全没有必要加，加得太多反而看着很累，而且也没有任何区分的意义。第三，没有将常用的变量缓存，这里最应该缓存的是this._options，要不然看起来很乱，而且缓存起来对性能也是有好处的。第四，对象的规划（命名）不清晰，比如this._options和this.opts什么关系？我反正是看不明白。第五，代码风格不统一，比如访问对象，之前都是this._options.height，为什么后面出来一个this._options.data['head']？用this._options.data.head不是更清晰么？第六，函数内变量名混乱（和第四点很像），比如第二个函数中id和_id什么关系？为什么不用aaaId和bbbId？cre又是什么，难道是createElement缩写？变量尽量起有意义的，可区分的名字。第七，函数名称表义不明，命名不符合大部分规范约定。第一眼看到_isHaveTable，我第一反应是，这应该是类似return true或者return false之类的吧。结果一看，这么长，难道返回在后面？又往后看了一眼，这根本就没有返回啊！那为什么要用_isHaveTable啊？_is开头的函数明明白白就应该返回一个true或者false啊。
在逻辑上不同的块之间多加空行，程序一下子看起来就明了很多
要写出好的优美的代码，不光光是看起来优美。其中要包含的东西太多太多，这里是讲不完的。推荐看看《代码之美》就算思路清晰，越写越乱其实也是难免的，下面提几点能显著提高代码质量的方式。如果有时间去做重构工作，那么对于“优美”能有很大的提高。编码第一步要做的是定义空class（大项目），或者是空的function（小功能）。理清楚他们之间的关系，确保这个基础上不会有问题之后，开始编写具体功能，做到这个当然要对需求做深入了解，确保之后的功能添加也不会导致原先代码结构的变动。如果，你使用了框架，那么遵循框架的编码风格，与命名规范。个人的习惯，不管做什么，我都会有个debug的地方，细节功能现在debug里面做初步测试。调试成功后，把优化过的代码再靠到业务流程。
说一句不好听的，你把方法写到this上，然后类名叫base 我就不想继续看了。有时间捉摸代码格式，还是建议多看看基础。。
说些术的东西。对比提问者与他人代码区别后发现，代码只有2层缩进，除去外层function，只有一层（我因为缩进多所以只用2个空格，而图中居然是4个）。所以关键在于架构而不是风格（虽然空格也是问题，但把图中代码加上空格可能还是会觉得不会太好看）。可以尝试多使用闭包，怎么复杂怎么来，就能写出优雅的代码了。申明，不是说胡乱使用闭包之类是正确的，只是一个必经的过程。
看了你的代码，一会用$，一回用javascript自带的选择器，能看出$只是 getElementById()封装，但是我觉得你应该编写一个css的选择器框架，或者干脆使用jquery。你的代码里面有太多太多的对dom的操作，这些重复的工作，就应该使用封装库，你就可以省去很多麻烦和重复。你可能会在考虑执行效率，但你这样也不一定能保证你的执行效率一定比jquery高。试着进行封装。试着重构。试着统一风格。试着使用优秀的第三方库和框架。推荐使用jquery，underscore, backbone，习惯这个框架后可以升级到angular
因为JavaScript真的是很乱的语言。写一段时间js再回头写Java会觉得很治愈。
推荐一本书，叫《代码整洁之道》，英文名叫《Clean Code》。从多个角度讲解了怎么把代码写得好读。
我是有点强迫症，写完一个脚本，甚至会花1个小时去处理格式。。为了避免下次看不懂。。别说用软件去整理，软件整理的很渣渣。。我算是非主流了。。【图解】新人报道 欧美岛国，要的私信我，多谢支持。表删帖_图解gv吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：37,724贴子：
【图解】新人报道 欧美岛国，要的私信我，多谢支持。表删帖收藏
1楼 10:58&|来自
登录百度帐号
内&&容:使用签名档&&
为兴趣而生，贴吧更懂你。&或Sina Visitor System苏宁易购美图m2手机晒单反200配件,私信小编是谁?_百度知道
苏宁易购美图m2手机晒单反200配件,私信小编是谁?
关键是我们看不到你的订单的内容，才能得到返还的赠品。你的订单中一定有要求把晒单的截图用私信发给”小编“，私信小编这里的私信是动词。小编姓氏名谁并不重要，小编是名词，就是发私信给小编的意思，也就无法为你分析如何发私信给他了属于小学低年级语文水平的提问
其他类似问题
苏宁易购的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁