Read the angular code style guide
This article was written on January 17, 2021
Original address:Angular document
This article has a complete code style guide – from how to arrange folders to how to name variables. But it is slightly bound to ng, so here are some general parts that can be taken out separately.
Please stick to each fileDefine only one thing(such as a service or component), and put the file sizeLimited to 400 lines of code。
Small files are usually very smallEasy to read and maintain, and canPrevent conflicts with the team in the version control system。
Small files are OKPrevent some hidden program defects, when multiple components are written in the same file, it may cause shared variables, create unexpected closures, or generate unexpected coupling with dependencies.
In general, the single responsibility principle can make the code more reusable, easier to read, and reduce the possibility of errors.
If the file is a function, pleaseInsist on defining simple functions, and limited to 75 lines.
This will make it easier for us to do unit testing.
Naming is a very important thing. It can let others see our code, or when we look at the previous code after a period of timeQuickly understand the document content, variable meaning, method purpose。 You can also search globally so that we canQuickly locate the target。
Code takes more time to read to people than to machines, so we need to carefully consider naming.
The following two principles can be followed:
- Stick to useConsistent naming rules；
- Adhere to followSame modeTo describe properties and types.
Ng it is recommended to use dots and bars to separate file names——In descriptive names, use horizontal bars to separate words; Use dots to separate descriptive names and types。
Specifically, it is to first describe the characteristics of the component, then describe its type pattern, and use the same type naming rules for all components!!!
Commonly used suffixes are
.directive。 If necessary, you can create more type names, but you must note that,Don’t create too many。
This naming file allows us to quickly identify what is in the file, and easily use the fuzzy search function of the editor or IDE to find a specific file type. Or provide pattern matching for automated tasks.
File name and symbol name
If you name the file
hero.service.ts, then the symbolic name, that is, the class / variable name, should be named
if it is
todo-list.service.ts, the is named
That is, useCapital hump nomenclatureTo name the class, match the symbol name with its file name, and append the agreed type suffix (such as component and service) after the symbol name.
Unit test file name
It shall be consistent with the test documents,
xxx.xx.tsThe unit test file name should be called
Structure organization and lift principle
We should strive to make the project structure and organization conform to the lift principle:
- Locate quick location code
- Identify at a glance
- Flattest try to maintain a flat structure
- Try do not repeat yourself
The importance of the above four principles ranges from large to small.
Lift provides a consistent structure withStrong expansibility、modularizationIt allows us to quickly lock the code and improve the efficiency of development.
In addition, the way to check whether the application structure is reasonable is to ask yourself:“Can I quickly open all files related to this feature and start working?”
Adhere to intuitive, simple and fast positioning of code.
If you want to work efficiently, you shouldMust be able to find documents quickly, especially when you don’t know (or remember) the file name – putting the relevant files together in an intuitive location can save a lot of time.
And the descriptive directory structure will brighten your eyes and those behind you!!!
You can use the above
Property + suffix + file typeTo facilitate our positioning
The name of the file should reach this level:When you see a name, you immediately know what it contains and what it represents.
The file name should be descriptive.The way to ensure the accuracy of the file name is to ensure that the file contains only one component.
Avoid creating files that contain multiple components, services, or mixtures.
It takes less time to find and ponder over the code and becomes more efficient.Longer file names are far better than shorter but confusing abbreviations.
Please keep the directory structure as flat as possible.
considerWhen the same directory is released to 7Create subdirectories when there are or more files.
Consider configuring the IDE to hide irrelevant files, such as the generated. JS file and. JS. Map file.
No one wants to find files in directories more than seven levels!!!
The flat structure is conducive to search.
On the other hand, psychologists believe that when people focus on more than nine things, they will begin to feel difficult. Therefore, when there are 10 or more files in a folder, it may be time to create a subdirectory.
It depends on your own comfort. Unless there is significant value in creating new folders, try to use a flat structure.
Try Do Not Repeat Yourself (T-DRY)
Stick to dry (don’t repeat yourself).
Avoid excessive dry at the expense of reading.
Although dry is important, it is not worth it if it is at the expense of other principles of lift. That’s why it’s called “try dry”.
Recommended directory structure
Insist on putting all the source code in a directory called Src.
Insist that if the component has multiple companion files (. Ts,. HTML,. CSS, and. Spec), create a folder for it.
The front-end directory structure I am used to:
- src - app -ModuleA // module B - assets - components - ... -Moduleb // module a -Shared // shared module - layouts - assets - main.ts - ...