该篇文章讨论了网站开发人员可能会收到的糟糕建议。文章列举了15条糟糕的建议,这些建议可能会导致网站开发过程中的问题和挫折。
文章首先指出了一些关于代码质量和结构的糟糕建议,例如“永远不需要注释代码”和“忽略代码性能”。这些建议可能导致代码难以理解和维护,以及性能问题。
下面是正文
尽可能使用多个抽象层,直到:
你应该在第一次审查时始终阻止拉取请求,以确立优势。一些变更请求的想法包括:
好的提交信息需要花费时间来编写。与其浪费宝贵的时间写一些像这样的东西,
[JIRA-1234] build: replace vue-cli with vite
可以使用以下命令将您的代码推送到一个空的提交消息中
git commit --allow-empty-message -m "" && git push --force
经常使用魔法数字来表明你确切知道自己在做什么
window.scrollTo({
top: 89,
left: 12,
behavior: "smooth",
});
永远不要让他们知道你的下一步行动,通过混合函数的返回语句
function shouldPayTax(income) {
if(income.amount < 20_000) {
return false
}
if(income.amount > 20_000 && income.country == 'USA') {
return true
}
if(income.country == 'Panama') {
return false
}
if(this.totalWorkingHoursPerWeek > 60) {
return true
}
if(income.amount > 20_000 && income.isCelebrity == true) {
return false
}
if(income.amount > 20_000) {
return true
}
}
如果有人胆敢在项目中添加TypeScript,你可以通过在任何地方使用 any 来绕过类型检查。
function add(a:any, b:any):any {
return a + b
}
在生产捆绑包中,以节省宝贵的字节为借口,使用 == 代替 === 。
除了编写难以理解的代码之外,留下毫无意义的误导性注释是让他人困惑的绝佳方式。
一些需要遵守的规则:
使用 props 传递状态是一种将组件层次耦合在一起并使重构变得更加困难的好方法。
另一方面,组件状态应该被移动到一个全局存储中,这样每个人都可以修改它。
以更好地了解组件的职责和能够在不同功能中重复使用变量的能力为借口,使用大型和单一的组件
一个代码检查工具可以分析你的代码,并检测潜在的错误、不一致性和偏离已建立的编码标准的情况,这显然是我们不希望出现的。
这两个片段之间的差异是显而易见的:
const props=defineProps({
elements:Array,
counter:{
type:Number,
default:0,
},
});
const{data,method}=useComposable();
const isEmpty=computed(()=>{returnprops.counter===0;});
watch(props.counter,()=>{console.log("Countervaluechanged");});
const emit=defineEmits(["event-name"]);
function emitEvent(){
emit("event-name");
}
function getParam(param){
return param;
}
const props = defineProps({
elements: Array,
counter: {
type: Number,
default: 0,
},
});
const { data, method } = useComposable();
const isEmpty = computed(() => {
return props.counter === 0;
});
watch(props.counter, () => {
console.log("Counter value changed");
});
const emit = defineEmits(["event-name"]);
function emitEvent() {
emit("event-name");
}
function getParam(param) {
return param;
}
专业提示:唯一可接受的使用规则是强制文件的行数超过一定数量。1000是一个不错的起始数字。
使用硬编码字符串总是一个好主意。但有时使用包含HTML元素和类的翻译可能会更好。
translation.key.name = Hello <span class="red">World!</span>
不写测试是一个不错的选择,但是拥有一个糟糕的测试套件可能会引起更多的沮丧。作为一般准则,一个测试应该是:
最后,防御性编程是给弱者和经验不足者准备的。为什么会有人想要伤害你呢?
vue工程npm run serve/start/dev启动时,node_modules文件报:Cannot read property range of null 错误,该问题是babel-eslint版本更新问题导致的;
在ajax请求后台数据时有时会报 HTTP 400 错误 - 请求无效 (Bad request);出现这个请求无效报错说明请求没有进入到后台服务里;原因:前端提交数据的字段名称或者是字段类型和后台的实体类不一致
我们都知道 try catch 无法捕获 setTimeout 异步任务中的错误,那其中的原因是什么。以及异步代码在 js 中是特别常见的,我们该怎么做才比较?
父页面初始化声明变量a为数组(数组对象是引用类型,赋值传递的是地址),创建iframe子页面后给父页面变量a赋值,赋值后销毁iframe子页面,再次调用变量a的时候就会抛出异常‘SCRIPT5011:不能执行已释放Script的代码’。
js错误的实质,也是发出一个事件,处理他,error实例对象message:错误提示信息,name:错误名称(非标准属性)宿主环境赋予
文件上传的功能时候,调用fs.renameSync方法错误,这个提示是跨区重命名文件出现的权限问题。先从源文件拷贝到另外分区的目标文件,然后再unlink,就可以了。
如果在JavaScript中使用innerHTML,缺点是:内容随处可见;不能像“追加到innerHTML”一样使用;innerHTML不提供验证,因此我们可能会在文档中插入有效的和破坏性的HTML并将其中断
现在,有越来越多所谓的“教程”来帮助我们提高网站的易用性。我们收集了一些在Web开发中容易出错和被忽略的小问题,并且提供了参考的解决方案,以便于帮助Web开发者更好的完善网站。
为什么要做前端错误监控?1. 为了保证产品的质量2. 有些问题只存在于线上特定的环境3. 后端错误有监控,前端错误没有监控,前端错误分为两类: 即时运行错误和资源加载错误
当我们在进行开发的时候,通常需要属于我们自己的错误类来反映任务中可能出现的特殊情况。对于网络操作错误,我们需要 HttpError,对于数据库操作错误,我们需要 DbError,对于搜索操作错误,我们需要 NotFoundError,等等
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!