js命名规则

JavaScript019

js命名规则,第1张

函数命名:统一使用动词或者动词+名词形式 ---- fnInit() 如果有内部函数则“_”开头  _fnInit(). 对象方法命名使用fn+对象类名+动词+名词形式  fnAnimateDoRun() 某事件响应函数命名方式为fn+触发事件对象名+事件名或者模块名  fnDivClick() 附常用的动词列表:变量命名: 一些算是默认的规范就不说了 (常量大写,循环变量简写,驼峰式等) 对于变量命名 还是没有一个规范,下面贴出一个别人的规范仅供参考。 按照类型规划: 按照前缀区分 :市面上常用的命名规范: camelCase(小驼峰式命名法 —— 首字母小写) PascalCase(大驼峰式命名法 —— 首字母大写) kebab-case(短横线连接式) Snake(下划线连接式) 1.1 项目文件命名 1.1.1 项目名 全部采用小写方式, 以 短横线 分隔。例:my-project-name。 1.1.2 目录名参照项目命名规则,有复数结构时,要采用复数命名法 。例:docs、assets、components、directives、mixins、utils、views。

今天小编要跟大家分享的文章是关于Web前端工程师要知道的JavaScript变量命名规范,正在从事Web前端工作的小伙伴们来和小编一起看一看吧,希望本篇文章能够对大家有所帮助。

JavaScript变量命名规范:只能由英语字母、数字、下划线、美元符号$构成,且不能以数字开头,并且不能是JavaScript保留字。

下列都是非常正确的变量命名:

varhaha=250

varxixi=300

vara1=400

vara2=400

varabc_123=400

var$abc=999

var$o0_0o$=888

var$=1000

var_=2000

var________=3000

下列都是错误的命名:

vara-1=1000//不能有怪异符号

vara@=2000//不能有怪异符号

var2year=3000//不能以数字开头

vara¥=4000//不能有怪异符号

vara*#$#$@=5000//不能有怪异符号

varab=300//不能有空格

下列的单词,叫做保留字,就是说不允许当做变量名

abstract、boolean、byte、char、class、const、debugger、double、enum、export、extends、final、float、goto

implements、import、int、interface、long、native、package、private、protected、public、short、static、super、synchronized、throws、transient、volatile

需要注意大写字母是可以使用的,并且大小写敏感。也就是说A和a是两个变量。

1varA=250

2vara=888

以上就是小编今天为大家分享的关于Web前端工程师要知道的JavaScript变量命名规范的文章,希望本篇文章能够对正在从事Web前端工作的小伙伴们有所帮助。想要了解更多Web前端知识记得关注北大青鸟Web培训官网。最后祝愿小伙伴们工作顺利!

JavaScript 源文件命名没有什么硬性规定或推荐标准,完全可以凭个人喜好命名,只要符合 URI/URL 命名规则即可,习惯使用短线(-)或句点(.)作为分隔符号,最好使用小写英文字符,不要使用其他符号和扩展字符(如中文字符)。也有一些命名惯例:

一般使用 .js 扩展名,这个扩展名的兼容性最好。其实任何扩展名都可以,只要是 text 类型、编码正确即可,但引用时须注明类型(type="text/javascript" 或 "application/javascript")及编码字符集(charset="UTF-8" 等等)。

一般使用短线替代自然语言名称中的空格,比如 jQuery UI 1.9.0 的源文件可命名为“jquery-ui-1.9.0.js”。

一般用句点分隔表示名称中的从属关系,范围大的在前面。比如你提到的 MooFx2 的(主模块)源文件就可命名为“moo.fx.js”,MooFx2 的可选特效包,属于 MooFx2 的子模块,可命名为“moo.fx.pack.js”;还有,比如 jQuery 的表单插件 Form,属于 jQuery 扩展插件,则可命名为“jquery.form.js”。

经过压缩的源文件可以使用“min”表示,区别于原始版本。比如经过压缩的 jQuery 源文件可以命名为“jquery.min.js”,YUI 则习惯命名为"yui-min.js"。

上面的惯例仅供参考,最终还是尊重个人习惯。不过如果你在项目中引用了某个框架或库,就最好优先使用他们的命名习惯。另外,一个项目中最好统一使用一种命名规则,这样方便自己和其他开发人员识别。