Good programmers explain their code in as simple a way as possible. Even physicists can explain wormholes with a blank sheet of paper and a pencil. So can we?

I try to make code as simple and readable as possible, including choosing appropriate variable names, using code conventions, and so on. But there’s something missing. Understanding code shouldn’t be about understanding “how” it’s implemented; it’s about understanding what you want to accomplish.

You can even make reading code like reading a novel, rather than a lot of code.

Three major themes are discussed below:

The problem

Reading someone else’s code can be excruciating, and without providing the proper context, we get lost in the search for the meaning of a function or attribute.

advice

In binary, low-level, and high-level languages, syntax is becoming more user-friendly in order to attract more developers. As the syntax becomes more like English, our code should be concise and self-explanatory.

The results of

Write good code that reads like a novel and is easy to read and understand (even without context).

In fact, as an ios developer, it is very important to have a learning atmosphere and a communication circle. This is my ios (QQ) communication circle

681503716 (Verification code: silence)

No matter you are small white or big ox welcome to enter, we exchange and study together

The function name

The correct way is:

We always write functions assuming that the person reading them has enough context to understand what the function is trying to accomplish. Naming functions with vague meanings such as “handleRedView()” can cause problems. What is “RedView”? What does this function basically want to do?

So in some cases the purpose of the function can be ambiguous, and it can be very difficult to read without providing enough context

We can classify functions into four categories:

The Informer function manages the Management function the Router function executes the Execution function

1. Notification function

Routing/admin functions are usually triggered, as shown in the following example:

A callback function that notifies you that something has/is about to happen and gives you a chance to respond.

Most often used for actions triggered by a delegate, or for notification handlers.

2. Management functions

Used to combine multiple functions for more advanced purposes, without relying on arguments, all code in a block executes.

The above functions contain all the necessary information and are executed when the car starts, at which point we don’t focus on “how” this is done, but on “what” it does

3. Routing functions

It is used to combine multiple functions for more advanced purposes and relies on parameters to execute only when we want to.

Routing functions are usually the same as point-to-execute functions, but in some cases, they can contain their own logic if the logic code is no more than one line.

4. Execute the function

The concrete implementation of the function name.

This results in a clean, short class that is readable and easy to maintain.

* As a rule of thumb, every function should have only one responsibility.

Avoid the bad habit of using “and” : playandplay () loadAndPlay() in function names. It can break the rule of single responsibility and write code that can accommodate both.

Avoid guesswork in function names: moveRedViewIfNeeded() is not clear because the above example causes subsequent programmers to have to drill into the function to understand when the RedView is triggered.

No, layoutIfNeeded() is not the case, because we know that if a view’s setNeedDisplay is true, it should be rearranged. This situation is common in the Swift language because functions are essentially application-private.

note

When it comes to code readability, the first thing THAT comes to mind is code conventions. They are generally accepted and widely used, but using code conventions does not necessarily improve code quality.

The “is” prefix should be used for Boolean variables and methods to explain that the return value is Boolean. # Coding specification

Since the “if” statement is always used for booleans, is it necessary to add “is” to every Boolean attribute? Why did Apple change the Swift syntax from view.hidden to view.ishidden? I can only think of one answer… Because ** “if view.ishidden” ** looks more natural.

Try using the “is” prefix as follows:

If a Boolean attribute/method of a class is used for instances of that class (exposed), there is a valid reason to use the “is” prefix

If the Boolean attribute is used inside the class (privately), the prefix is redundant.

While it is possible to use a private set and use this property publicly, this approach allows for encapsulation.

Encapsulation is used to hide the value or state of a structured data object in a class, preventing direct access by unauthorized parties.

So if you’re not dealing directly with a Boolean, how do you name it?

Private var playerIsPlaying: Bool private var gridConstraintIsEnabled() ‘is’ needs to point to something: view.ishidden,’ is’ points to view. This principle is used in the example above, playerIsPlaying, “is” refers to the player.

/if isPlayerIsPlaying {}/ contrast /if isPlayerIsPlaying {}/ which is more natural? I think you already have the answer.