前端小白的几个坏习惯

简介: 前端小白的几个坏习惯

最近在教授前端小白学员编写一些简单的网页。在这个过程中发现了小白们比较容易遇到的一些问题或者坏习惯,在这里对它们进行一一解释。


文件名命名


有些学员的文件命名是这样的:

image.png

除了网页的内容外,所有的东西都应该用英文,而不是拼音。

原因有如下几点:

  1. 编程不是一个人的活动,是群体活动。我们使用的编程语言、框架和库,几乎全部都是英文。使用中文,你的协作者会难以理解你的代码。而且中英混搭会让代码阅读困难。
  2. 使用拼音和使用汉字基本上没有什么区别,甚至还不如汉字直观。
  3. 拼音很难加音标,而且即使能加音标,也很难表达真正的意思,因为同音词太多,它存在多义性,比如 heshui,你不知道它到底是在表达喝水还是河水。
  4. 使用拼音会让你显得非常不专业。
  5. 坚持使用英文编程,有利于提高英语水平。

如果英语不好,刚开始可能会难以忍受,但是一旦熬过去开始这段时间,坚持下来,将会是长期的回报。

如果你英语实在是非常差劲,可以借助一些翻译软件。比如世界上最好的翻译网站:translate.google.com/,虽然是 Google 的域名,但是大陆并没有墙。

不止是文件名,变量、函数等事物都应该使用英文命名。

使用英语,越早越好。


文件类型命名


有些同学的文件命名是这样的:

image.png

文件命名的问题上面已经解释了,这里主要来看文件后缀名的问题。

应该使用小写 .htm/.html 结尾。

原因有如下几点:

  1. 不同的操作系统处理大小写是不一样的。Windows/Mac 系统大小写不敏感,Linux 系统大小写敏感。统一命名方式会具有更好的移植性。

比如我们有如下目录结构:


├── cat.html
├── dog.html

下面的代码在 Mac/Windows 系统上正常。


<a href="./Dog.html">跳转到狗的页面</a>

但是在 Linux 系统上会出现 404。

我们开发时通常是在 Mac/Windows 系统,这时问题很难暴露,但是部署时通常是在 Linux 系统,就容易导致开发时正常,部署时异常的不一致性。

  1. 易读性,事实证明小写的单词更易于阅读。
  2. 便捷性,文件名和后缀名都保持小写,不需要额外按下 Shift 键了。
  3. htm 和 html 的区别是,在老的 DOS 系统上,文件后缀名最多只支持 3 位。所以很多语言都会把文件后缀名限制成 3 位以内。现在的操作系统已经没有这个问题了,所以 htm 和 html 的作用是完全一致的。如果你追求简洁一点,那么使用 htm 时完全没问题的。


代码格式化


有些同学的代码是这样的:

image.png

VSCode 提供了 prettier 插件,我们可以使用它对代码格式化。

代码格式化有以下优点:

  1. 代码格式化后更易于阅读和修改。比如它会自动帮你添加空格、对齐、换行等。
  2. 不需要去刻意学习代码样式了,代码格式化工具会帮你做好,并且在这个过程中你会潜移默化的学会怎么样调整代码样式。
  3. 使用统一的代码格式化,可以帮助大家在协作时保持一致,不会有比必要的争议。
  4. 新人加入项目时也可以更容易地融入到项目,不会看到风格迥异的代码。
  5. 在代码合并的时候也可以减少冲突的发生。

建议一定要开启代码格式化。


补充说明


这部分和文章内容无关,是针对评论区进行补充。

掘金没有评论置顶功能,我没办法逐一回复评论区。所以只能在文末进行统一解释。

很多人在评论区说本文水,或者在拿拼音的事情抬杠。本来我不想解释,但是负面评论的人确实不少。

我说两点。

第一,文章标题开头四字明确表明目标群体是前端小白,小白是什么概念能明白吗?一定是「xxx源码解读」才是干货硬货?

第二,关于中文好还是英文好,我不想继续争论。我从业多年,看过无数项目源码,从后端 Java JDBC、Spring、JVM、Go 到前端 React、Redux、Webpack、Babel,无一例外全是英文。或者你随便找个初具规模的互联网中大厂或者外企的程序员,看看他们公司是不是有不让用拼音和汉字的规范。

程序员群体普遍的毛病就是固执己见。永远只是站在自己的视角去观察世界,看到的永远都是自己想看到的。然后去贸然指责,这样真的会显得自己很没有修养,而且很无知。

哪怕做不到感同身受,也应该给予应有的尊重,哪怕难以理解,也不要随意贬低。这是做人的基本修养。

掘金是技术分享平台,不是贴吧/知乎。我写文章的本心只是分享内容,没有收各位一分钱。

文章内容对你有价值的话,非常感谢你的点赞支持。

文章内容对你无用的话,退出去就好了。

言尽于此。

能看懂就看,再看不懂就直接屏蔽我吧,谢谢配合。


相关文章
|
前端开发 Linux Windows
前端小白的几个坏习惯
最近在教授前端小白学员编写一些简单的网页。在这个过程中发现了小白们比较容易遇到的一些问题或者坏习惯,在这里对它们进行一一解释。
132 0
前端小白的几个坏习惯
|
2月前
|
存储 人工智能 前端开发
前端大模型应用笔记(三):Vue3+Antdv+transformers+本地模型实现浏览器端侧增强搜索
本文介绍了一个纯前端实现的增强列表搜索应用,通过使用Transformer模型,实现了更智能的搜索功能,如使用“番茄”可以搜索到“西红柿”。项目基于Vue3和Ant Design Vue,使用了Xenova的bge-base-zh-v1.5模型。文章详细介绍了从环境搭建、数据准备到具体实现的全过程,并展示了实际效果和待改进点。
178 2
|
2月前
|
JavaScript 前端开发 程序员
前端学习笔记——node.js
前端学习笔记——node.js
49 0
|
2月前
|
人工智能 自然语言处理 运维
前端大模型应用笔记(一):两个指令反过来说大模型就理解不了啦?或许该让第三者插足啦 -通过引入中间LLM预处理用户输入以提高多任务处理能力
本文探讨了在多任务处理场景下,自然语言指令解析的困境及解决方案。通过增加一个LLM解析层,将复杂的指令拆解为多个明确的步骤,明确操作类型与对象识别,处理任务依赖关系,并将自然语言转化为具体的工具命令,从而提高指令解析的准确性和执行效率。
|
2月前
|
存储 弹性计算 算法
前端大模型应用笔记(四):如何在资源受限例如1核和1G内存的端侧或ECS上运行一个合适的向量存储库及如何优化
本文探讨了在资源受限的嵌入式设备(如1核处理器和1GB内存)上实现高效向量存储和检索的方法,旨在支持端侧大模型应用。文章分析了Annoy、HNSWLib、NMSLib、FLANN、VP-Trees和Lshbox等向量存储库的特点与适用场景,推荐Annoy作为多数情况下的首选方案,并提出了数据预处理、索引优化、查询优化等策略以提升性能。通过这些方法,即使在资源受限的环境中也能实现高效的向量检索。
|
2月前
|
机器学习/深度学习 弹性计算 自然语言处理
前端大模型应用笔记(二):最新llama3.2小参数版本1B的古董机测试 - 支持128K上下文,表现优异,和移动端更配
llama3.1支持128K上下文,6万字+输入,适用于多种场景。模型能力超出预期,但处理中文时需加中英翻译。测试显示,其英文支持较好,中文则需改进。llama3.2 1B参数量小,适合移动端和资源受限环境,可在阿里云2vCPU和4G ECS上运行。
127 1
|
2月前
|
前端开发 算法 测试技术
前端大模型应用笔记(五):大模型基础能力大比拼-计数篇-通义千文 vs 文心一言 vs 智谱 vs 讯飞vsGPT
本文对比测试了通义千文、文心一言、智谱和讯飞等多个国产大模型在处理基础计数问题上的表现,特别是通过链式推理(COT)提示的效果。结果显示,GPTo1-mini、文心一言3.5和讯飞4.0Ultra在首轮测试中表现优秀,而其他模型在COT提示后也能显著提升正确率,唯有讯飞4.0-Lite表现不佳。测试强调了COT在提升模型逻辑推理能力中的重要性,并指出免费版本中智谱GLM较为可靠。
前端大模型应用笔记(五):大模型基础能力大比拼-计数篇-通义千文 vs 文心一言 vs 智谱 vs 讯飞vsGPT
|
3月前
|
SpringCloudAlibaba JavaScript 前端开发
谷粒商城笔记+踩坑(2)——分布式组件、前端基础,nacos+feign+gateway+ES6+vue脚手架
分布式组件、nacos注册配置中心、openfegin远程调用、网关gateway、ES6脚本语言规范、vue、elementUI
谷粒商城笔记+踩坑(2)——分布式组件、前端基础,nacos+feign+gateway+ES6+vue脚手架
|
4月前
|
存储 前端开发 JavaScript
前端语言串讲 | 青训营笔记
前端语言串讲 | 青训营笔记
51 0
|
6月前
|
JSON 前端开发 JavaScript
前端Ajax、Axios和Fetch的用法和区别笔记
前端Ajax、Axios和Fetch的用法和区别笔记
117 2
下一篇
DataWorks