During the recent internship, I had some communication with another intern partner. After all, I had the same skill level and focused on the same technical points, so it was easy for me to communicate and learn. Working in an outsourcing company before, I had more project experience than my partner. I found some things that he did not pay much attention to in the process of project development and had some ignorance. Here I sort out some programming instructions, mainly to share some experience (entry-level, don’t brag to the boss).

Preparation of IDE tools

“A good tool is half the battle.” Every time I start a project, I will choose the appropriate tool according to the situation of the project. The tool here is not only an editor, but also a debug environment, which is easy to debug. There are other words of good “to do a good job must first sharpen his” said, that is the reason why the premise of good tools tend to be successful, don’t don’t believe this, some people are afraid of the trouble would not be in the local in the deployment environment, and direct your N long before the deployment server online environment, however, is not suitable for the environment), At this point, I recommend using the Vagrant development environment, as detailed in my previous tutorial on Vagrant Deployment. (www.jianshu.com/p/492bdee41)…

Editor recommendation

I recommend the jetBrains series of editing tools for my own experience. This series of ides all work perfectly with git versions. For those who are afraid of the command line, try my Git graphical tutorial

Postman debugging

I don’t want to use me to introduce too much, a developer of the back end, this tool is necessary, the left is I saved some API interface directory address, need to use the time directly click debugging, really convenient and fast.

Coding standards

Every programming language has its own code for where Spaces are appropriate, where blank lines are appropriate, underline or hump, and there are a few verbs that you should know about:

  • E.g. Please do as you please.
  • MUST NOT, MUST NOT, MUST NOT
  • SHOULD: This is strongly recommended, but not required;
  • SHOULD NOT: Strongly NOT recommended, but NOT required;
  • MAY and OPTIONAL: The word “OPTIONAL” is used less frequently in this document.

If you are a PHP developer, it is generally the PHP PSR standard specification that follows this set of standard specifications

Learning to debug is very important

Whether you learn any language, need a basic skills – debug, there is a good saying “development five minutes, debug 2 hours”, will not debug, there is no debug consciousness, understand not to understand debug skills, is an important sign of entry programming. Just like reading English in primary school, noting “Chinese pronunciation” next to English words is something everyone does. If you never learn how to pronounce words, you might just read the words you note. This is something that needs to be learned and learned as we code, and web tutorials and documentation don’t emphasize how to debug.

Learn to read the wrong information

Most problems do not arise directly at the code level, but at runtime. This would normally cause the program to interrupt and output error information. Generally, the location and reason of the error can be seen from the error message. Many beginners are afraid to read the wrong information, this is not good. Even if English is not good, also try to see, the routine is so much, see a few times you are probably familiar with, but for your debugging help is very big.

Sometimes, however, the error is displayed in the wrong position. This is usually because the parenthesis or quotation marks on the preceding line are wrong, causing the following code to be confused. So if you can’t see where the error is, try looking ahead.

Use try… Except can prevent the program from being interrupted due to exceptions. However, do not use exception handling during development, otherwise it prevents the issue of error information and affects debugging.

The error information is also useful to be copied directly into the search engine, and Google’s results are better than Baidu’s, and the English site is better than the Chinese site. (How to use Google is not a topic that can be discussed publicly here.)

Breakpoint debugging, log Check log file error information

Output and analysis of logs in a program is a very basic but very flexible and effective way to debug. Using print is the most common way to log.

The main functions of log are:

  • Determine the path of the program. Print information about whether a function was called, whether an if block was executed, how many times a while loop was executed, and where it was interrupted.

  • View the status of variables. The program’s own error report will tell you what happened, but you also need to find out why it happened. Print to print the values and types of related variables involved in the error statement, which can help analyze the error cause.

  • Find out where it went wrong. Often, the cause of the error is not in the location of the error, so print more tags and print variable values in different locations to see the changes in the value of the variable during the running process, so that you can observe where the problem occurs.

Tips for debugging through log:

  • More output of some auxiliary information, to facilitate their own view, or a pile of data to see eye. For example, I usually print the name of the variable, the type of the variable, and the value of the variable. Such as:

  • Output before the error line. The variables involved in the error line, their values and types, are all printed out to see if they match expectations.

  • Do one thing at a time. If you call multiple functions or operations in a row, write them separately and print them separately.

  • For strings, direct print is escaped and decoded, affecting the observation of the actual value of the variable. You can view it as print(repr(text)) or print([text]).

  • For coding problems, good use of the type method and Chardet library auxiliary judgment. This has been explained in the previous article related to coding. You can check the reply pycharm in the public account.

  • It is also common to output the log to a file for easy logging and backtracking of the problem. There are also dedicated logging modules for this.

(Above content, from CSDN blog garden)

Familiarity with a framework

Early is to use, focus on the framework structure, after understanding the framework of the design pattern and concept when you master a language after you can draw inferno: casually give you a framework, look at the development document for a while, you can start to knock code; The next level of nature is to directly organize and build their own framework. (It’s not.)

Good at summarizing

Well, like our team mates, do not forget the original intention to study hard, the teacher called us n years ago: good memory is not as good as bad writing, more reading and more writing and more practice, EMmm, the writing is finished, I should go to work!!