代码规范是软件开发领域经久不衰的话题,几乎所有工程师在开发过程中都会遇到或思考过这一问题.而随着前端应用的大型化和复杂化,越来越多的前端团队也开始重视代码规范.同样,前段时间,笔者所在的团队也开展了一波开源治理,而其中代码规范就占据了很重要的一项.接下来的几篇文章,将会对JS代码规范.CSS规范.Git提交规范.Git工作流规范以及文档规范进行详细的介绍~ 系列文章: 前端规范之JS代码规范(ESLint + Prettier) 前端规范之CSS规范(Stylelint) 前端规范之Git提交规

Web 前端代码规范 最后更新时间:2017-06-25 原始文章链接:https://github.com/bxm0927/web-code-standards 此项目用于记录规范的.高可维护性的前端代码,这是通过分析 Github 众多前端代码库,总结出来的前端代码书写规范. 目录 前端普适性规范 HTML 规范 CSS 规范 JS 规范 License public domain, Just take it. Thanks @Ruan YiFeng: https://github.com/

eslint+prettier+husky+lint-staged 统一前端代码规范 遵循编码规范和使用语法检测,可以很好的提高代码的可读性,可维护性,并有效的减少一些编码错误. 1.终极目标 团队中的所有开发人员用一套代码规范规则,并且无需我们花太大的精力去为了格式而格式.希望有一套自动化工具,帮我们检测代码是否规范,如果不规范,则自动能够帮我们按照既定规范格式化. 实现这一目标需解决的问题: 1.代码规范落地难:面对开发规范经常面临的现状是很难落地,总是"拆东墙补西墙",归根结底在

web前端的代码规范主要针对的是HTML,CSS和javaScript代码. 前端代码规范在不同场合会有差异,但是规范的前端代码应该具有以下特征: 1.符合标准 所谓的标准是指W3C指定的web标准,包括语言的规范,开发中使用的原则和解释引擎行为等,主要有三部分组成:结构标准(html和xhtml部分).表现标准(css部分)和行为标准(javascript部分). 2.格式规范统一 前端代码的格式主要包括命名.代码缩进.空格和空行的使用以及代码注释.命名主要有HTML元素的id和class名,

前言 上一篇博客,我们简单的介绍了grunt的使用,一些基础点没能覆盖,我们今天有必要看看一些基础知识 [grunt第一弹]30分钟学会使用grunt打包前端代码 配置任务/grunt.initConfig 前面我们简单的介绍了grunt相关的知识,这里我们这里还需要再熟悉下Gruntfile相关的知识点,比如说配置任务 grunt的任务配置都是在Gruntfile中的grunt.initConfig方法中指定的,这个配置主要都是一些命名性属性比如我们上次用到的合并以及压缩的任务配置: grun

前端工程师对写标准的前端代码的重视程度很高.这些最佳标准实践并不是那个权威组织发布的,而是由大量的前端工程师们在实践过程中的经验总结,目的在于提高代码的可读性,可维护性和性能.那么接着上一篇,我们再来谈谈CSS代码的一些标准实践. 1,命名 和其他语言规范一样,css的命名也讲究命名要有意义,命名要尽可能短但是要足够表达含义:命名的词用连字符连接. 不规范的命名: #navigation{ } .demoimage{ } .error_status{ } 规范的命名: #nav{ } .demo

1. WEB标准是什么? “WEB标准”是一系列标准的总称.一般的误区经常把WEB标准说成DIV+CSS.准确的说法应该是:采用W3C推荐的WEB标准中的XHTML1.1结合CSS2.0 样式表制作页面的方法.DIV 应该指的是XHTML标签,而CSS 指的是样式表. 2. 采用WEB标准开发的好处 2.1 节约运营成本   2.2 用户友好性 2.3 内容跨平台的可用性 2.4 加快页面解析速度 2.5 更良好的用户体验 3. 名词解释 1. 横切 页面中950px宽并且对高度没有限制的容器称

前言 前文<RESTful API实战笔记(接口设计及Java后端实现)>中介绍了RESTful中后端开发的实现,主要是接口地址修改和返回数据的格式及规范的修改,本文则简单介绍一下,RESTful过程中前端代码的改变以及前后端分离的一些想法. 整合代码及修改计划 在这次的代码修改过程中,后端改动相对较大,而前端代码的改动更多的是配合后端修改,主要是请求接口的url及js的ajax请求部分,修改后的代码更加符合RESTful规范: function saveArticle() { var tit

基于git的简单实用的版本管理规范及流程,包括:代码库的分布.人员角色的划分.代码提交合并流程.代码冲突处理.分支管理. 代码库分类 根据代码库分布的位置及作用,分为以下几类: 主库:位于服务端,所有开发的代码最终都要合到主库. 个人代码库(服务端):从主库fork出来,位于服务端.每个人自已开发的代码,由本地的git库push到每个人自己的个人代码库(服务端),再由个人代码库(服务端)合入主加. 个人工作库:位于每个开发人员的开发机器,从个人代码库(服务端)clone到本地.每个开发人员开发的

最近公司因为业务增多,又招了一个iOS小伙伴,内心无比开心呀.但是多了一个人,日常代码开发就要统一规范起来,方便日后维护和查找.下边列一下我日常用到一些代码规范. (一).SVN规范 1.代码一定要先update,(解决冲突),然后在commit. 2.代码提交. [人员][动作][动作内容] 如果代码中增加.修改文件,要写清楚增加了那个模块,那个文件夹,做什么功能的. 如果对代码进行删除,一定要和PM确定这个文件无用了,然后再删除文件,同时记得删除服务器上的文件. 如果对文件进行移动,要写清楚

一.常用的前端文件的组织结构: 1.js (放置JavaScript代码) lib(放置框架JavaScript文件) custom.js 2.css(放置CSS样式代码) lib(放置框架CSS文件) images(放置用于样式中的背景图) reset.css( 统一元素默认样式的样式文件) custom.css(业务相关样式文件) 3.resource(放置页面图片文件以及其他类型资源文件) 4.index.html 代码文件整体按照文件类型的不同归类,同一类型的代码文件则需要安装具体的业务

前言 代码重构是业内经常讨论的一个热门话题,重构指的是在不改变代码外部行为的情况下进行源代码修改,所以重构之前需要考虑的是重构后如何才能保证外部行为不改变.对于后端代码来说,可以通过大量的自动化测试来确保重构后的代码逻辑,可对于普遍缺乏自动化测试的前端代码来说,重构之前一定要考虑再三才能下手. 有效地重构代码 我曾经有一次不算太成功的前端重构经历,所幸的是没有导致太大的问题,但教训是惨痛的.此次重构的项目本身没有足够的自动化测试,尤其是针对前端的自动化测试,所以在重构之前也预想到了重构的风险.先

这篇文章主要介绍了使用mini-define实现前端代码的模块化管理,十分不错的一篇文章,这里推荐给有需要的小伙伴. mini-define 依据require实现的简易的前端模块化框架.如果你不想花时间学习require.js,也不想翻看长篇的cmd/amd规范,那么这个mini-define就是你不错的选择.如果你之前用过sea.js或require.js那么mini-define更加高效,更加轻量,更加易用.项目地址:github 用法 首先定义模块 定义模块 一:定义模块用define函

  1.背景 在多人协作项目中,如果代码风格统一.代码提交信息的说明准确,那么在后期协作以及Bug处理时会更加方便. 先来介绍本人公司采用的commit规范 Commit message格式 <type>: <subject> 注意冒号后面有空格. type 用于说明 commit 的类别,只允许使用下面7个标识. feat:新功能(feature) fix:修补bug docs:文档(documentation) style: 格式(不影响代码运行的变动) refactor:重构

有一段都在重构之前文章<我和我的广告前端代码(三):一次重来的机会,必要的技术选型>中提到的广告前台展示项目,原有的基于页面的请求,改成了单广告位请求在这个过程中经历了好几次架构变更以及项目刹车.回过头来看看,感觉收获很大的.才刚刚把前台展示弄完,又开始了新的挑战——后台投放. 其实原来也是有投放系统的,自从我去年接手的时候就有了一个庞大的后台投放系统.这个系统的后台写的还是很不错的,但是由于当时前端团队人员较少,整个系统的页面就变成了,前端做个静态页,后端套模板的实现方式了.由于后期由后端同

Prettier 简单使用 ESLint 与 Prettier配合使用 首先肯定是需要安装 prettier ,并且你的项目中已经使用了 ESLint ,有 eslintrc.js 配置文件. npm i -D prettier 配合ESLint检测代码风格 安装插件: npm i -D eslint-plugin-prettier eslint-plugin-prettier 插件会调用 prettier对你的代码风格进行检查,其原理是先使用 prettier对你的代码进行格式化,然后与格式化

这个作业属于哪个课程 软件工程 (福州大学至诚学院 - 计算机工程系) 这个作业要求在哪里 Beta冲刺 这个作业的目标 团队进行Beta冲刺--代码规范与计划 作业正文 如下 其他参考文献 ... 一.代码规范 代码规范 二.任务计划 日期 计划 第一天 (05.19) 完善前端代码 第二天 (05.20) 完善前端代码 第三天 (05.21) 微信授权 第四天 (05.22) 房间-数据库 存入 搜索 查看 第五天 (05.23) 房间-数据库 存入 搜索 查看 第六天 (05.24) 房间

前言 一般在团队开发中每个人的代码习惯都不太一样,这样就会导致代码风格不一致,以致于维护和修改bug的时候看别人的代码成为一种痛苦...这种情况尤其在前端开发中尤为明显.因为关于前端的开发规范貌似也没有行业权威标准.这几天在网上看了下,基本上在开发中通过eslint进行约束,airbnb的标准貌似颇为推崇,今天稍微整理下,准备在日后开发中形成习惯. 基本规则 每个文件只包含一个React组件.eslint: react/no-multi-comp:(官方表示在无状态,或者Pure组件允许一个文件

git & Angular git commit 规范 https://github.com/angular/angular/commits/master https://github.com/angular/angular/commit/e82f56b96f2beff420354dbb10ad84a99ef03325 header (type + message) body footer refs xgqfrms 2012-2020 www.cnblogs.com 发布文章使用:只允许注册用户

基于虎书实现LALR(1)分析并生成GLSL编译器前端代码(C#) 为了完美解析GLSL源码,获取其中的信息(都有哪些in/out/uniform等),我决定做个GLSL编译器的前端(以后简称编译器或FrontEndParser). 以前我做过一个CGCompiler,可以自动生成LL(1)文法的编译器代码(C#语言的).于是我从<The OpenGL ® Shading Language>(以下简称"PDF")找到一个GLSL的文法,就开始试图将他改写为LL(1)文法.等

什么是代码耦合?代码耦合的表现是改了一点毛发而牵动了全身,或者是想要改点东西,需要在一堆代码里面找半天.由于前端需要组织js/css/html,耦合的问题可能会更加明显,下面按照耦合的情况分别说明: 1. 避免全局耦合 这应该是比较常见的耦合.全局耦合就是几个类.模块共用了全局变量或者全局数据结构,特别是一个变量跨了几个文件.例如下面,在html里面定义了一个变量: 在html里面定义全局变量             XHTML   <script> var PAGE = 20; </s