I can't bear it anymore, I won't be happy if I don't vomit.
I won’t write technical articles in this issue. I will just complain about the weird codes in the company’s projects. They are all written by some senior front-end developers. I hope you will take a look at them.
Know what is bad code, to write good code.
Don't say that if only one of the code and the person can run, it's a joke.
It's understandable to write junk code when everyone has the resources, but it's a bit unjustifiable to still write junk code after working for several years.
The garbage code I think is not that you can't write depth-first and breadth-first algorithms, nor that you can't write publish-subscribe and strategy patterns if else.
I think all junk codes have one thing in common: they make you sick to your stomach. It’s code that makes you naturally uncomfortable and gives you a headache when you look at it. For example, the layout is extremely ugly, with no spaces, no line breaks, and no indentation.
Excellent code is concise and clear. if else It doesn't matter if you can't use strategy mode optimization. A few more lines of code will have little impact. As long as you are clear, it is good code.
With the basic standards of bad code and good code, let's not talk nonsense, let's take a look at the differences of these senior front-end codes.
---------------------------------------------renew---- -----------------------------------------------
Let’s focus on answering the questions in the comment area:
1. The project was originally a project of a major factory and was written by the outsourcing team at that time. The overall code is okay. eslint, commitlint and the like are also available, but these can all be disabled, and their effect depends entirely on personal awareness.
2. Later, the project was acquired by our company, and the original people became employees of our company to support other projects. The code of this project will be replaced by our new batch of maintenance. It is true that a lot of code was left behind three or more years ago. It is understandable for anyone who did not write bad code when they were young. It's just that the code was written three years ago. Why do some people write it simply and clearly, and split it clearly, while others are so messy and messy?
3. A lot of the code mentioned in the article was actually written in the past year. The front-ends who wrote these functions all had six or seven years of experience. At that time, because the project team had just been formed and there was no front-end, these front-ends were transferred to support. The things written were really It's very, very non-standard. It's hard to understand. Did they also write code like this in the original project team (the core products, front-end infrastructure and specifications are very good)?
4. Regarding team norms, the current team has just been established. They are all young people, and the leaders are not professional front-end. They are basically in a state of no front-end. I really want to push the norms, leader but I am not in the position. It’s not good. To promote these things and make suggestions, the leader hopes that you can simply write about the business (to put it bluntly, I am not leader saying that everything is useless). Moreover, we young front-end users all turn it on by default eslintand are very conscious, so we are content with the status quo for the time being. We have review done the code a few times and there are no major problems, so we have not continued to do it.
5. Some people in the comment area said they wanted to see the code I wrote. I mentioned it in my previous article. I have several open source projects. If you are interested, you can check it out yourself. The code on the project cannot be displayed because it involves company confidentiality.
6. This article is just a complaint, and it is not directed at anyone. If someone feels uncomfortable reading it, yes, it is you. If it's okay, everyone can enjoy watching it. Squirt~
File naming is weird
The same function was all written by him. There are three folders with three weird naming methods. The most important thing is the third one. Does anyone know what the function of this folder is? I have no idea what I wrote. Every time I look at the code, I have to reorganize the logic.
Component responsibilities are unclear
It’s the same component just now. This components folder should contain various components, but it also puts a root component at the bottom RecordDialog.jsx . So what’s the point of using components it as a file name?components
Conditional rendering logic is placed at the bottom
Here he actually wrote several rendering functions to render different content conditionally according to different customers and needs. However, the judgment conditions should be placed outside the function and together with the function call. Different rendering functions are called according to different conditions instead of functions. The conditions are written inside, which leads to built-in logic, which is too scattered and not conducive to maintenance. It violates the programming concept of high cohesion and low coupling that we often say.
Abuse and misuse of TS
The project was three or four years ago, and it mainly consisted of class components. The senior front-end staff were seconded internally to support maintenance. I found that the project didn't even TS have one, which was ridiculous, so I hurriedly added TS it. Matched, wrote a tsx suffix, and then all typeless or anyscript. It even completely ignores TS and ESlint complete code inspection, leaving a bunch of red error reports in the code. Unbearable, I added the type myself.
Leave a lot of useless comment code and error code
To feel the amount of commented code, I delete it every time I make a request, but I really can’t delete dozens of projects.
Ugly, hidden, ineffective, confusing css
Ugly: no spaces, no line breaks, no indentation
css Hidden dangers: A large amount of code covering the original style of the component library , and implementation without writing class namesnamespace
Invalid: A lot of commented css code, all kinds of garbage class names with class names but no styles.
Confusing: css Files are introduced from global, local, and other components, causing the style code to be too coupled.
6 slots in one file
Slot 1: The format of blank lines in the code is confusing, which affects code reading
Slot 2: Empty function, write the function name but not the function body, but still call it!
Slot 3: Too many function parameters and not optimized
Slot 4: The chain call is too long, the attribute may exist undefined or null the situation, the code is easy to collapse, resulting in a white screen online
Slot 5: Double loop nesting, affecting performance, can be replaced by reduce processing
Slot 6: The names of parameters, variables, and functions are arbitrary and not semantic, and they do not know what their functions are at all, and they do not use camel case names
Abnormal chain value acquisition and assignment
I’m too lazy to say it, so viewers can watch it for themselves.
Unreasonable code splitting or failure to split the code causes the number of lines of code to exceed the standard
Anyone who can write so many lines of code is definitely a talent.
Although the maintainers later added some code, the initial code was at least close to the standard 2000 .
This is a data flow file for a certain function. Dva The amount of code required to use and maintain it is much Redux less, but you can still write so much in one file. As a result, no one dares to move it until now.
Miscellaneous useless js, md, txt files
Before I managed it, it was filled with a lot of useless and scattered md documents, files with only one function but no calls js , and a bunch of files for testing html .
If I can't stand it, I just create a folder and put it together, it looks much more comfortable.
Mix less and scss
This is the weirdest.
Special variable renaming
This is a real boss, he built the entire project infrastructure. The things written are also very good, bug very few. But the boss has some personal preferences, for example, he likes to window rename G. Although this is not a big disadvantage, I really don’t recommend you do this. window It is a variable with special meaning, so please don’t rename it.
js
复制代码
const G = window;
const doc = G.document;Confusing import
The standard import order should be third-party libraries such as frameworks and components first, followed by internal component libraries, packages, etc., then some tool functions, auxiliary functions and other files, followed by style files. The messy import order is annoying to look at, and there is also this weird introduction method, which is to directly lib import components in the folder, which is also weird enough.
All in all, css files are generally introduced last, and those that cannot be blocked js are imported first.
write at the end
Let’s just complain so much first, these are mistakes that are easy to make in the usual development process. I hope everyone will take this as a warning, otherwise be careful of getting stabbed.
If you want to maintain a good coding habit, you must always tell yourself when writing code that someone will look at your code later. If you don't want to be scolded, write it cleanly.
I think algorithms and design patterns are secondary. If the code is clear, the data flow is clear, and the variables are well named, it will basically 80% not be too bad.
But having said all that, success depends on people.
However, I wrote an article explaining how to write concise and clear code. I think it is not only the front-ends that are one year old that need to learn, but also the old front-ends that are six or seven years old.