前端岗位编写代码注意规范

38 篇文章 4 订阅
29 篇文章 10 订阅

🔥🔥🔥关注前端小王hs🔥🔥🔥
🔥🔥🔥加底部微信🔥🔥🔥
🔥🔥🔥学习指导/前端练手项目推荐/毕设选题/面试资源🔥🔥🔥

前言:继写了前端岗位初入职场后的最初一段时间需要做什么这篇文章之后,反响强烈,也是上了综合热榜前二十,所以今天接着写关于前端岗位编写代码注意规范

为什么要对代码进行规范?

这篇文章主要是面向一些在中小企业前端岗位工作的程序员,因为大部分的中小企业并没有去编写 《代码规范手册》 这类规范文档,所以很多刚毕业或者初入前端岗位的同学就没有代码规范这方面的意识,比如在模板中嵌套七八层的<div>,然后这样就会对渲染页面产生不好的影响,又比如为了方便写样式而出现大量的行内样式

对代码规范有什么好处

对代码进行规范,概括的来说有以下几个方面的好处

易于查找和解决bug

先举个反例,如果在一个项目中,对css样式,有的程序员写的是行内样式,有的程序员是写在<style>中,而有的程序员在写完后又单独封装了一个css/scss文件,虽然我们可以通过ctrl+F进行快速定位,但如果我们在本页面没有找到,是不是又要看本文件引入的样式文件夹在哪?这无疑就浪费了开发的时间

利于团队开发合作

一个项目如果是个人开发,那可以随心所欲的进行开发,但如果是团队项目,那就有最少两到三个前端程序员进行开发,每个人可能有不同的开发风格,如果每个人都按照自己的风格去开发,那写出来的代码可阅读性对于其他的程序员来说就是一个难点。

比如有些程序员写出来的组件可能觉得代码我自己看得懂就行了,没有去考虑其他的程序员可能要复用组件,当其他的程序员想要复用的时候就感觉头都大了,写的函数是什么意思一时间内搞不懂,还需要花费时间去阅读分析,又浪费的开发时间

易于后期维护代码

当一个项目开发到一定阶段的时候,项目中可能有大大小小几十到几百个文件夹,我们通过对每一个文件夹名和代码文件名进行规范,到时如果甲方对项目的某个前期开发的模块不够满意,那么我们也可以根据代码规范快速定位到目标文件的目标代码,并对代码的样式,功能进行重写

培养自己的良好开发习惯

代码就像是程序员手中的武器,而武器总是需要不断的进行锻造强化才能配得上日益强大的自己,所以从刚入职前端岗位便培养自己的代码规范思维,对自己未来的路也是有很好的帮助的

总结为什么要规范代码

总的来说就是从三个角度去想为什么要规范代码,一是为团队,良好的代码易于他人阅读,利于团队开发,二是为自己,良好的开发习惯对自己未来的路有很大的帮助,三是为后人,如果自己离职跳槽,可以对后来的程序员讲解自己写的代码规范,确保项目顺利过渡

常见的代码规范思路

目录名规范

项目的名字都是英语,因为一个名字可能对应不同的英语单词,所以在开发项目的时候必须对文件名进行规范,如果程序员英语基础不好,建议下个翻译软件,并且整个项目组统一翻译软件,比如管理员工列表的模块
员工
可以统一使用staff:全体员工或者employee:雇员

文件名规范

在vue中,尽量少用或者不用index进行命名
index
因为如果这样开发后期会出现大量的同名文件,进行文件检索的时候会出现问题,要按具体的页面或者组件功能进行命名

比如这个vue文件是封装的按钮文件,就改成Button.vue

同时为了严谨首字母要大写

类名规范

在开发过程中,我们为了样式会采用一层外壳容器包一层内容的写法,所以在类名规范上,要统一规定是外层容器类名和内层容器类名还有内容类名
类名
例如:

<!-- 头部外壳 -->
<div class:'header-wrapped'>
	<!-- 头部内容 -->
	<div class:'header-content'>
		<!-- 头部内容列表 -->
		<div class:'header-contnet-list'>

类名规定采用-进行衔接单词,这样在样式文件中可以更直观的看出哪一层包哪一层,当然用sass/scss进行嵌套也是一眼可以看出

不要使用浏览器本身自带的类名,比如table,border之类的,会发生样式冲突

注意:不要用拼音,用拼音会显得类名很长,其他命名规范也适用这条规则

注释规范

注释一般用中文,如果开发组有外国人,就得多种语言

函数名规范

函数名一般采用驼峰命名法,比如点击会改变某个按钮颜色,我们可以写成@click='changeColor'

导入模块书写规划

建议如果是导入少的话,用单行,导入的模块多,就比如分别导入element中的组件的话,用多行

//单行或多行
	import { ref,nextTick } from 'vue'

	import {
		ref,
		nextTick
	} from 'vue'

HTML规范

不要嵌套很多层,最多嵌套三层,为了避免渲染dom的时候浪费资源,有些大厂会规定缩进,这里不做叙述,因为面对的是中小开发企业,如有兴趣了解也可以网上找找对应的开发手册资源

样式规范

①尽量少用或者不用行内样式
②尽量使用CSS 预处理语言如sass/scss,里面的嵌套和复用可以减少代码量并且更好的看清样式层级
单独引用样式文件,减少主文件的代码量,便于分别维护模板和样式
引入css文件
在样式中做好注释,每一层样式是对应哪一个html区域的
注意回流和重绘问题
⑥尽量使用缩写属性,即background-color:red我们可以写成background:red

选择器问题

通常我们需要拿到某个元素去修改样式或者操作某些功能,我们就可能用到id选择器,类名选择器,标签选择器之类的,规范使用类名选择器,不要去使用id选择器,防止污染全局样式

常量命名

上面我们说了类名用-,函数名用驼峰命名,那么对于常用,我们可以使用下划线_去命名,这样可以区分不同的类型命名

布局上规范

如果我们的页面上出现了一个每列宽距都相同并且还有好几行的区域,我们可以使用表格或者栅格布局去实现,这时我们就要统一规范面对这种情况或者其他衍生出来的不同页面的此类情况,什么时候使用表格,什么时候使用栅格布局

运行完删除log代码

我们在页面中做请求测试会使用到console.log,当我们写完接口渲染完页面并且没有bug的时候,就要删掉log代码

路由path规范

对于路由和子路由中的name,path等,对名称和路径有个统一的规范
路由

总结

具体的规范其实可以细化至很细节的部分,比如上面提到的缩进,当然对于一般的中小企业工作的程序员来说,有些不一定是必须,过于严谨也会造成不必要的压力,所以项目组在开发项目之初需要考虑前端岗位编写代码注意规范手册范围,充分考虑本项目的实际难度的同时对程序员的代码熟练程度进行考量,这样才能对项目的代码进行一个完整的规范

中小企业的程序员如果对代码规范有想了解的想法,可以去找找这方面的资料,如果目前公司没有代码规范,可以跟项目总监提出这类想法,对于项目的开发和个人的成长都是非常有好处的

如有错字还请谅解,码字不易谢谢支持
关注前端小王hs,关注原创前端好文

  • 3
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

前端小王hs

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值