随着发展的逐步发展,作为工程师除了需要关注需要写的⻚面,样式和逻辑之外,还需要面对日益复杂 的系统性问题,比如模块化文件的组织、ES6 JS 文件的编译、打包压缩所有的 JS 代码、优化和合并图片静态资源等等事情。
规范化是前端工程化的一个重要部分。现在,有许多工具能够辅助我们实行代码的规范化,比如你一定知道的 ESLint 和 Prettier。
它很纯粹,就一个代码格式化工具,并不会做代码质量的检查(比如声明了一个未被使用的变量)。
https://juejin.cn/post/6947872709208457253
在真实的工程项目中,尤其是多人协作的场景下,代码规范就变得非常重要了,它可以用来统一团队代码风格,避免不同风格的代码混杂到一起难以阅读,有效提高代码质量,甚至可以将一些语法错误在开发阶段提前规避掉。但仅有规范本身不够,我们需要自动化的工具(即Lint 工具)来保证规范的落地,把代码规范检查(包括自动修复)这件事情交给机器完成,开发者只需要专注应用逻辑本身。
很多同学不知道深入研究一些技术的意义在哪,会用不就行了?花那么大精力深入原理有什么好处呢?
Flow 是 facebook 出品的 JavaScript 静态类型检查工具。Vue.js 的源码利用了 Flow 做了静态类型检查,所以了解 Flow 有助于我们阅读源码。
当前,前端项目支持代码规范校验、代码格式化已经必不可少,同时需要支持代码提交前对代码格式校验预检查,这里提供一份最简单的配置供大家参考。
假如团队中的小伙伴在提交代码时没有遵循规范要求,例如只写了一个"修改"或"更新,这会给团队中其他小伙伴造成困扰呢,不得不花时间查看代码和推测逻辑。
最近在和同事合作开发一个项目,忘记一开始约定好项目的规范和格式,导致大家都按照自己的习惯去配置了eslint,prettier,当合并代码后就有了下面的情形:
昨日本该更新文章,是围绕前后端模块的(因为前两天是按计划写linux以及网络模块)。但昨日实在没想出要写什么文章, 心态处在一个尴尬的境地,简单的知识点觉得没必要搬运,但是深入的东西不是花个一天半天就能写的出来,况且现在也有不少朋友关注我,写文章得认真对待,左思右想干脆就没写了。
In computer programming, lint was the name originally given to a particular program that flagged som
本文从代码规范,代码检查,代码格式化,以及编辑器自动化实现的方向,介绍代码规范统一在我们团队的实践应用。
作者:杨成功 原文:https://segmentfault.com/a/1190000040948561
Flow 是 facebook 出品的 JavaScript 静态类型检查工具 Vue.js 的源码利用了 Flow 做了静态类型检查,所以了解 Flow 有助于我们阅读源码
大家好,今天要介绍一个超棒的工具链——Biome,它是为网络项目量身打造的,旨在为开发者提供维护项目健康的工具。
在上一篇文章中,我们介绍了使用mpvue开发小程序所需要的一些开发环境的搭建,并创建了第一个mpvue小程序代码骨架并将其运行起来。在本文中,我们来研究熟悉一下mpvue项目的主要目录和文件结构。
Git Hooks 就是在 Git 执行特定事件(如commit、push、receive等)时触发运行的脚本,类似于“钩子函数”,没有设置可执行的钩子将被忽略。
又是一期提升开发效率的热点速览,无论是本周推特的检查 Python 语法和代码格式的 ruff,或者是 JS、TS 编译器 oxc,都是不错的工具,有意思的是它们都是 Rust 写的。
在上一节中,我们看到了构建 React 应用程序时的所有挑战以及一些可以帮助我们处理这些挑战的很好的解决方案。在这一节中,我们将查看项目结构和初始化工具,这些工具构成了我们项目的良好基础。
各种命名风格,各种冗余代码,各种缩进风格,各种奇葩注释和各种没有注释,眼中有码,心中无码,只有心累两个字,项目的整洁度会受到很多客观因素的影响,为了自己的身心健康,我们应该试图将这种影响降到最低。简单地说,统一格式和风格的代码让人更加赏心悦目,更不容易让你产生想摔键盘的冲动;用一个B格更高的词语,叫做“熵减”,也就是降低团队产出代码的无序性,如果你想在未来成为一名合格的前端架构师,这将是你的工作目标。
通常,代码编辑器(或IDE)的插件会帮我们做一些静态语法检查的工作,但是如何自定义语法规则,如何集成到开发流程中,仍然需要我们花一些时间去了解。
一、问题痛点 在团队的项目开发过程中,代码维护所占的时间比重往往大于新功能的开发。因此编写符合团队编码规范的代码是至关重要的,这样做不仅可以很大程度地避免基本语法错误,也保证了代码的可读性。 对于代码版本管理系统(svn 和 git 或者其他),代码格式不一致带来的问题是严重的,在代码一致的情况下,因为格式不同,触发了版本管理系统标记为 diff,导致无法检查代码和校验。 但是需要知道的是,开发规范不仅仅包含代码格式规范,还有很多内容,这里只是单独说明代码格式化规范而已。 (一)关于代码格式规范问题 代
https://www.npmjs.com/package/lint-staged
团队多人协同开发项目中困恼团队管理一个很大的问题是:无可避免地会出现每个开发者编码习惯不同、代码风格迥异,为了代码高可用、可维护性, 如何从项目管理上尽量统一和规范代码呢?
在日常开发中,每个人的代码编写习惯都不尽相同,比如有的人喜欢在代码末尾加上分号,而有的人不喜欢加,在个人开发的项目中这并不是什么严重问题。但在团队协作开发时,我们往往需要阅读其他人所写的代码,此时没有一个统一完整的代码规范,无法有效的控制代码质量,进而影响团队的开发效率。通过引入代码规范工具,可以帮助我们保障一个团队的代码风格相同,并且能能避免一些因为格式上的问题,而出现的低级错误
写在前面:开发过程中,会遇到很多繁杂精细的麻烦问题,虽然知道要去按照步骤解决,但总归耗费大量的时间,那为什么不去寻求一个捷径,本文总结了一些在线工具,遇到问题,打开网页,想要的东西,分分钟就能解决,让开发变得高效,快速,有了这些工具在手,就可以从繁重的工作任务中解脱出来,有大把的时间去王者峡谷散步打野浪一圈了。 一:Atool在线工具: http://www.atool.org/ aTool,工具在线工具,由华中科技大学一位在校女研究生开发的在线工具集合网站,旨在做出最简单方便、最完整干净、最全面完整的工具
讲代码规范的文章很多,但是很可惜没有一篇文章能讲好讲全,其他文章没完成的工作,就让这篇文章来完成吧。
Eslint 可以静态检查 javascript 代码一些逻辑上的错误,还有一些代码格式的错误。原理是把代码 parse 成 AST,然后基于 AST 来检查一些问题。
猫哥是一个常年混迹在 GitHub 上的猫星人,所以发现了不少好的前端开源项目,在此分享给大家。
笔者个人观点看来,想要完全掌握前端工程化,那么就得对行业现有的构建工具、流程管理、服务管理有一个全面以及深入的认识,无论是前端还是后端开发者,我们通过任意编程语言编写软件应用,这是基本能力,但作为工程师,我想那就是得具有工程化的能力,我们应该在开发工程中能够具有把控全局的能力,有业务上的视野,也得有技术上的沉淀,应该时刻思考,从程序设计、流程设计、方案设计上尽可能得去逼近符合业务场景的最佳实践。
1. 代码质量问题:使用 / 编写的方式有可能有问题 (problematic patterns)
前端工程化,是面向公司的代码模块化、系统化、规范化的一个过程,在这个过程中,经过了这个过程,我们才能称得上是“正规军”。
如果已安装Visual Studio Code,打开命令行工具,输入code --version命令,检查版本号是否为1.45.1及以上版本;可以正常返回版本号,说明环境变量设置也正确。
这里建议先复习一下《再唠叨JS模块化加载之CommonJS、AMD、CMD、ES6》
【前端科普系列】帮助阅读者了解web前端,主要覆盖web前端的基础知识,但不深入讲解,定位为大而全并非细而精,适合非前端开发的同学对前端有一个系统的认识,能更好的与前端开发协作。尽可能的写成科普类文章,对于前端开发而言,只适合刚入门的新手。
使用 vue2-cli3 开发时,js 和 vue 文件经常报 eslint 语法格式警告,可以通过以下VS Code设置,在保存源代码时自动格式化。
按照ES模块机制组织源码,辅以类型检查和Lint/格式化工具,借助Yarn处理模块依赖,HUBOT检查PR;Rollup + Closure Compiler构建,利用Error Code机制实现生产环境错误追踪,DevTools侧面辅助bundle检查;Jest驱动单测,还通过格式化bundle来确认构建结果足够干净;最后通过npm发布新package
在现代前端和后端开发中,数据格式和代码格式的转换是一个常见的需求。为了提高开发效率和代码的可维护性,使用云库工具转换可以极大地简化工作流程。本文将介绍一系列强大的在线转换工具,帮助开发者轻松处理各种数据和代码格式的转换需求。
在开发人员中,关于最佳编辑器之争从来都是一个无休止的话题,从古至今,这个话题从来没有探讨出一个满意的结果。
看完 《前端规范之Git工作流规范(Husky + Commitlint + Lint-staged) https://www.cnblogs.com/Yellow-ice/p/15349873.html》,再次修改本文
很多前端小伙伴在日常使用prettier的时候都或多或少有一点疑惑,prettier在每一个IDE中究竟是怎样工作起来的,为什么配置有时候生效,有时又毫无效果。为了让我们的前端小伙伴更加熟悉这块,本文将对prettier在主流IDE中的使用过程一探究竟。
Prettier 和 ESLint 是两个互补的工具,它们共同确保代码的风格一致性和质量。Prettier 负责格式化代码,而 ESLint 则执行更复杂的静态分析和规则检查。
配置过代码格式化的同学一定纠结过如下问题:Eslint和Prettier都能格式化代码风格,是单用Eslint,还是两个一起用呢?
就从我的题目说起,本篇文章告诉你针对定制代码规范和检查这个小需求如何做出亮点?看完本文后回顾上面提到的 4 点,感觉下。
领取专属 10元无门槛券
手把手带您无忧上云