Give your function name a good name

Make writing a habit together! This is the second day of my participation in the “Gold Digging Day New Plan · April More text challenge”. Click here for more details.

1. Say it first

So called coding level, in most cases, you can see the whole picture by looking at your variable names.

This is a matter of experience, including the developer’s understanding of the business, understanding of the language style, the accumulation of development experience, and the study of open source projects. It’s going to feed back into the variable name.

To the big picture, and outlook on life is similar. We live in a society where we don’t all have to make trade-offs. Or choice.

This is especially true in the computer world.

The names should not be too long or too short. Long can accurately explain its meaning, but it is difficult to make mistakes, the amount of words, the editor’s automatic complement selection will also make you dizzy, choose the wrong. It’s too short, and the description is weak.

That’s why IT takes me a long time to write good variable names.

2. Four naming conventions for variables

2.1 Hungary:

Forget it. Ides were not as smart as notepads. It is not easy to determine the type of a variable. So there’s the Hungarian naming convention, which requires prefixes of variable types. So int iUsers, float fMaxLength

Just take a look

2.2 small hump

The first word starts with a lowercase letter and the rest of the words start with a big letter.

const userList = [];
const windowTitle = "";
Copy the code

2.3 PASCAL (large hump)

It corresponds to the small hump. Every word starts with a capital letter

2.4 Underline Naming

Between these two nomenclature. We also use underlining when we use constants. For example, const USER_LIST. But the underscore naming extends to other variables. The spacing between words is not case-sensitive, but is separated by underscores.

const user_list = [];
const window_title = "";
Copy the code

I didn’t use an underline name before I developed Flutter. After using it, I found that it is really good to use underscores when naming files, and the structure is clear.

2.5 other

Because of the precompilation tools sass and less, and stylui are variable. Their presence changes a small difference in CSS naming conventions. Things like BEM,SMACSS,SUITCSS can still be used, and variables can still be combined with one of the above three.

3. Function naming methodology

3.1 Common Verbs

Juejin. Cn/post / 701613…

3.1.1 Guidelines for the use of abbreviations

First, don’t use abbreviations if you’re not sure they are generic. Our goal is to ensure readability, not to create artificial barriers to collaboration that will be weeded out by colleagues if you leave the company and no one can read the code.

Second, make sure that the entire code has a uniform style, do not write and write.

Third, the abbreviation exists as a word, in the naming not WeChat but WeChat.

3.1.2 Common abbreviations

The bard	abbreviations
define	dev
function	func
information	info
statistic	stat
message	msg
internationalization	i18n
to	2
for	4
button	btn
background	bg
respository	repo
response	res
request	req
image	img
error	err
navigator	nav
parameter	params
utility	util
high order component	hoc
prroperty	prop
attribute	attr
template	tpl
source	src
horizontal	hoz
veritcal	vert
envirnment	env
boolean	bool

If any of these abbreviations look familiar, they are generic.

Catch-up => i18n, I + 18 letters + N. I don’t know which character started it

To => 2, for example fen2Yuan is used to convert fractional units into units

3.1.3 Function naming

I had already written the outline, but I thought I could fill in the gaps and did a search on the Internet. Found a big guy wrote quite detailed, I write words have no meaning, deleted deleted. Please refer to the front-end naming rules and naming methods of each scene to solve the pain of taking variable names!!

3.2 The problem of named length

Long names are not terrible, but rather the destruction of the principle of knowing by name in order to shorten variable names. Typically, react’s life cycle is highly semantic.

componentDidMount() {}
componentWillUnmount() {}
componentWillReciveProps() {}
getDerivedStateFromProps() {}
sholdComponentUpdate(){}...Copy the code

There are some mistakes on it. This is what happens when you don’t have a code editor 🥲. This is the downside of semantics. It’s not realistic to get it right the first time without a code prompt. But you can easily tell from these long function names what it does.

Although I don’t think the length of the name is important, I recommend no more than three words in practice. Of course, if you don’t think four words is enough, go for longer. The name is the first principle.

If you must use more than three words, you can combine them with the following namespaces.

3.3 Make use of namespaces

Built-in apis in browsers are best practices for namespaces. For example, window.math.random () uses random functions.

For this point, I in the first life before work, first learn norms and then write code in the article also have related elaboration

Here’s an example:

A shopping cart interface, I have four operation logic, delete items in the shopping cart, batch delete, add delete number, modify item SKU, we can write like this:

const cart = {
  items: [].delItem() {},
  delItems() {},
  addItem() {},
  updateItem(){}};Copy the code

Instead of cartDeleItem(){}, cardDelItems() {}, cardAddItem() {}.

In, for example, a library function, the method for filtering a specified number:

const tool = {
  filter: {
    number: function (value) {
      return /[1-9]\d+/.test(String(value)); ,}}};/ / call
tool.filter.number("666");
Copy the code

3.4 Unified Naming

This is very important, whether you use numbers, pinyin, or even abbreviations. As long as the overall situation is unified, it is not an unpardonable sin, maximum life imprisonment.

You use ABC to get user data, and cba to get user data. This is generally recommended to pop on the spot

Setting, config, configue, conf, etc. Forgive, but don’t do it.

3.5 Make a clear distinction

Similar names, different at the beginning or the end, not in the middle.

For example, getChineseVariable, getEnglishVariable and getJapaneseVariable are the three names that are hard to tell apart in the middle.

It is much more comfortable to program getValChinese, getValEnglisth, and getValJapanese

3.5 Do not exclude Chinese naming

This picture was seen on Zhihu a long time ago. At first glance, they were all named in Chinese. But on closer inspection, these variables are really hard to express. It requires that you have a good command of English, and that your team have a good command of English. This is very difficult at home.

So in this case, using The Chinese name may be a better choice.

3.6 Plan in coding first

This is an old methodology. It can be applied throughout the life cycle of a project. Even in life.

At work, when you get the requirements, don’t rush to write them. The best you can do with code as you go along is not to have to go back to the drawing board, not code quality.

Understand the requirements, split into various functional modules. After starting to write code, the whole is just the naming or structure is not too bad.

3.7 Look at the source code

Study the open source code, give yourself code improvement is not just the understanding of the language, the understanding of programming, it is a comprehensive improvement. That naturally includes an understanding of naming.

There will be a common tacit understanding between the good source code, read more, for a variety of abbreviations and naming habits will naturally be able to do know the chest.

For sites like Codelf. In addition to borrowing their names, you can also click on the name to see other context, to clarify the idea of naming in someone else’s context.