Why do you put tabs before and after =?

Perhaps it's written in developer preferences or copies, but it looks like there are no rules.

As a prerequisite, the rules and commitments are coating conventions (also known as coding style) for each programming language.
Coating conventions are enforced differently by language.

In many cases, there are no rules for the language itself, but
Examples of Kotlin where the language's official website publishes conventions and guides, and
Examples of Google C++ Style Guide where language-based companies publish coating conventions to the outside world,
For example, the language itself is a Go language with strong conventions.

Another prerequisite is a formatter that analyzes the code and automatically shapes the code for official coating and famous conventions.
Examples include gofmt in the Go language and autopep8 in compliance with Python's conventions PEP8.

Now, regarding the rule of your question, there should be a minority of rules that use tab characters before and after assignment operators and comparison operators that connect left and right sides such as equal.(In the first place, since 2010, there have been fewer cases of using tab characters for indentation [space/tab to start lines])
A quick look at WordPress Terms clearly states that indentation uses tab characters but does not use tabs before or after the operator.
However, PHP coding conventions PSR say "Use 4 spaces for indentation and no tabs" and the rules may differ even in the same language.

While the rules are not consistent, the most important rule for developers is the coding convention which is decided internally.
If you have a document that is clearly stated, follow it.
If only one person ignores me according to the me rule, the successor will be confused as the question.
Also, troublesomely, it often happens that company regulations are not clearly stated or that each department has a dialect.

Even if only one variable is declared, this way of writing
"However, how to write ""="" with spaces before and after each other

As for the above, a mysterious tab may be created by copying a well-formed code, another person may modify it later, and the rules may change, or you may make mistakes in the death march.

Therefore, best practices for writing programs are

• Verify the existence of explicit rules
• Other than that, somehow follow the coding style of the past
• Ask your senior if you don't understand anything
• Get a code review
when you've done most of the code above.

I think that's what it means.

In addition, if undefined rules are rampant, The devil will pop out of your nose, so if you take this opportunity to clarify your company's coding conventions, it may be valuable information.

By the way, PEP8 says Too much consistency is an expression of a narrow mind.
It is rare for the company to keep regulations in place, so it is also very effective to understand that it is too strict to pay unnecessary labor and refactoring costs.