Frontend sentiment-entry level

In the past few weeks, I have read a variety of code. After a bunch of code review, I also have some basic coders. I plan to record it, so that I can come back later if I forget it. I wanted to write this article last week. As a result, I was called back to fix the bug on Sunday evening ..

The following are recorded in CSS and Js.

CSS:

In the traditional sense, as long as CSS writing can present the effect, and the previous selector should not be too long. In this way, when the project is relatively small, it is very convenient to modify. However, when the entire project starts to expand, CSS will become extremely large. Over 1000 lines of CSS can be easily written.

In the review process, we can find that most of CSS cannot be reused. A button style can only be used on the current page, but cannot be used as the base class of the button for the entire website. Therefore, here, there is a concept that the element style in the page is pieced together by a bunch of classes, each class has its own style, such:

The publishing button below the blog garden editing article has the following style:

input.Button {    float: left;    background: #6B86B3;    border: 1px solid #333333;    text-transform: uppercase;    margin-right: 15px;    color: #FFFFFF;    font-size: 12px;    font-weight: bold;    width: 70px;    text-align: center;    cursor: pointer;    height: 26px;    line-height: 22px;}

This is our usual habit of writing CSS. If you write it in a slide style, you can go home, wash it, and sleep. However, these styles can only be used on the following three buttons, and the rest of the buttons cannot use these styles.

Of course, we can extract the CSS from it so that most of its code can be used throughout the site. As follows:

.leftFloat {    float: left;}.button {    border: 1px solid #333;    text-transform: uppercase;    font-weight: bold;    margin-right: 15px;    text-align: center;    cursor: pointer;}.largetButton {    width: 70px;    height: 26px;    line-height: 22px;}.smallFont{    font-size: 12px;}.whiteFont{    color: #fff;}.darkBlueBackground {    background:  #6B86B3;}

After doing so, the total number of lines of code seems to increase, but its reusability is greatly improved. For smallfont, whitefont, leftfloat, darkbluebackground, and so on, these classes can be unrestricted in this button. For All fonts, I can use smallfont and whitefont. In this way, the original input. button will be assembled by some column classes to display the button effect, as shown below:

<Input type = "Submit" class = "leftfloat button largetbutton smallfont whitefont darkbluebackground" name = "editor $ edit $ lkbpost" value = "publish" onclick = "Return checkinput (); "id =" editor_edit_lkbpost ">

Of course, this is meaningless for websites with small scales and simple styles. For websites with their own display specifications, complex styles, and large scales, this requires class assembly in HTML later, after customizing the brief CSS of the current page, you can quickly complete the development of a page.

JS

In JS, I was awakened after being scolded for countless times. In the past, I always liked to write code that looks tall, and it is said that it is still very efficient. It is much easier to use than traditional code. However, such code is completely written to the machine. In a multi-person team, the Code should not only be written to machines, but also to people. In this regard, you can even sacrifice a small amount of performance to make readable code. (Note that it is a small part! For example, write more var statements)

Here is something about passing parameters. Generally, when writing a function in JS, there are two main types of parameters used:

// Slide function a (A1, A2, A3, A4, A5, A6, A7, A8 ){//......} // a bunch of models // Options = {A1: '', A2:'', A3: '', A4:'', A5: '', A6 :'', a7: '', A8:''} function a (options ){}

There is an advantage in the parameter-specific method, that is, it clearly lets others know what input you need and what you need for your program to run. This makes it easy for later people to take over. However, a long string of parameters hanging behind the function is really difficult to see. If you want to add a parameter, you need to add a name later. I don't always feel very elegant.

The parameter heap method in options is pleasing to the eye. This writing method is very simple. However, in this case:

Function A (options) {balabala; B (options );};

Function B (options) {balabala ;};

In this case, to know what is in options, you must find B. This is a simple case. If there is a 5-6 layer call, it will be crazy.

Some people say that comments can be used. When we write the code for the first time, we will comment the comments. However, when people later modify your code, there is no time to change the comment, which forms a pitfall.

My practice is as follows:

function a(options){    //input start    options = options || {};    var a1 = options.a1;    var a2 = options.a2;    var a3 = options.a3;    var a4 = options.a4;    var a5 = options.a5;    var a6 = options.a6;    var a7 = options.a7;    var a8 = options.a8;    //input end    //processing    //output start    return {        a1: a1,a2: a2,a3: a3,a4: a4,a5: a5,a6: a6,a7: a7,a8: a8    };    //output end}

At the beginning of the function, I clearly stated what I want and what values are passed out when I go out. Options is only used in input settings, and will not be called in the subsequent function bodies. In this way, although the function is long, in the development of the team, it is more conducive to others' understanding of your code. In your specific processing, someone else can use it as a black box, only add the statement in the input, and add a few sentences after processing to complete the modification. This saves development costs.

Small tips:

We often worry that the passed objec or function is undefined. In this way, it is easy to report errors later. However, you do not need to worry about this:

function a(options){    options = options || {};    var testFunc = options.noFunc || function(){return {};};    //...}

In this way, even if no options or options. nofunc exists, no errors will occur when you call options. balabala or execute testfunc in subsequent calls. Of course, in testfunc, the type of the return value of the default function should be the same as the type returned by the original nofunc, so as to better enhance the program stability.

 

It seems that I accidentally sprayed CSS on the blog of the blog Park, hoping that the blog will not be killed ....