前端对代码更优雅的需求

 前端是个很非凡，带点矛盾的职位。所以我们的“前端攻城师”也大都是些矛盾体。矛盾在理性和理性之间，矛盾在文艺和三俗之间，矛盾在听任和严谨之间。作为所谓的“攻城师”，攻的不只是“前端”这座善变诡异的高城，还也是在攻我们本人关于艺术和编码的心防。www.591xyx.com
【关于HTML】
 --语义化
 语义化，是什么？即用准确的标签做准确的事。我不断以为学一种编程言语和学一门我们惯例意义里的“言语”如汉语，英语，其实是相似的。单字和单词以及语法都是一门言语的构成局部，但却不是最主要的局部。怎样去组织这些单字和语法去表达准确的意思才是言语的精华。这就比如汉语我们每小我都邑写，然则能用汉语写出冷艳的散文，写出逻辑严谨的小说的又有几多呢？所以，我们通俗人和一些优异的作家的最大的区别或许不在于晓得单词的几多，调查语法的几多，而在于叙说一件工作，表达一个观念时的思想。。。
 仿佛扯远了。回到html的语义化上。我说了，重点不在于你知晓标签的几多。哪怕你知晓了一切标签，甚至能区分了分歧的DTD下契合标准的标签。那又怎样样呢？仅仅同等于熟背了一本《现代汉语辞书》。每个标签都有他本人的语义。这也是为什么我们会丢弃用table来结构的方法。由于table原本的语义很清楚，就是“数据表格”，他该为数据表格而生，而不是为结构而生。
 举一个一线互联网公司一个关于合理运用html标签的书面考试题：

小明说：
小王是刚来公司的前端工程师，对公司内部的\"FED\"称呼不调查，你给他分析下吧。

我把一本《前端攻略》送给了小王，他很快乐。
 请把一段简略的html写成你感觉标准的，优雅的html。
假如我们思索到标签的闭合，思索到标签的巨细写。于是我们会如许改：

小明说：
小王是刚来公司的前端工程师，对公司内部的\"FED\"称呼不调查，你给他分析下吧。

我把一本《前端攻略》送给了小王，他很快乐。

 假如我们思索到合理运用标签。为什么要两个br连用？其实那边应该曾经可以分为两个段落了。所以：

小明说：
小王是刚来公司的前端工程师，对公司内部的\"FED\"称呼不调查，你给他分析下吧。

我把一本《前端攻略》送给了小王，他很快乐。

  假如上面一段html呈现在一个内容充分的页面里，其实根本也可以了，可是，假如我们假定我们一个页面的首要内容就是上面那一小段html，或许甚至一个页面就那一小段。那么，或许我们还需求更好的语义去润饰：

小明说：
小王是刚来公司的前端工程师，对公司内部的\"FED\"称呼不调查，你给他分析下吧

我把一本《前端攻略》送给了小王，他很快乐。

  到此为止，在某些状况下上面的强语义的方法是合理的，而或许某些状况上面的代码片段是有些冗余的。正如我们用汉语写文章，润饰的描述词用少了会感觉无味，用多了会显得口胃重。所以，合理的判别文档在页面的权重以及用合理的标签去润饰它显得尤为主要。
  --明晰地构造，与显示别离
 说到html构造，我不得不说一种经典的思维：面向对象。OO的思维自从在经典的C言语中被推行开来后，不断长兴不衰，面向对象确实是编码中当前为此最为优雅的方法。有人或许会说，你说c，c++，java等面向对象的编码，我能了解，你说JavaScript也能面向对象的编码，我也能承受，至于html和css也能面向对象？这就有点唐突了。是的，html和css一个作为“置口号言”,一个作为款式表。可否真正的出现面向对象的思维有待讲究。但是这并无妨碍我们把OO的思维贯串于我们的编码中。
 我们晓得。html是以“盒模子”为根底的，那我们无妨就面向“盒子”这个对象来架构我们的html。比方一个典型的“盒模子”相似：
   

       

       

       

   

 假如我们把如许一个盒子作为我们的“基对象”的话，那么html的构造会相似于下面如许：
  这只是一个根本的例子,有些box能够没有title，有些能够不需求footer，依据实践状况随机而变即可。
 至于构造与显示的别离，应该照样和一些小标准更有关系，如：
  --不要运用内联款式
  --不要运用带显示层的标签，如,,,

...等等
   【关于css】
  --款式的别离和聚合
  世界上一切的事物都遵照的“物极必反”的事理，而这个事理在css的编码里显得尤为分明。这时分“中庸”就显得尤为主要了。
 我们需求高效的，少冗余的css，所以会倡导css的别离，亦即OO-css。可是假如css别离的太彻底了，在html的维护上会是很大的问题，等于是牺牲了html的可维护性与局部优雅来成全一种过火和绝对的oo-css。这明显也是不合理的。
 我们在html文档里界说css款式衬着类名用的是class这个属性。提到class，在编码言语里是一个默许的“类”的代名词。也就是说，其实css的作者其真实创作css的时分其实就是基于“类”来思索的，要否则也不会用class这个词作为css款式的属性名。
 这天然不奇异，oo-css的思维很早就有人提出来了，可是世上总有些矛盾是难以谐和的，思索下面的css：

    .con-text {
        padding: 8px 10px;
        background: red;
        border: 1px solid #CCC;
        color: blue;
    }
   

test

  假如我们需求多个如许相似的p，但又要求文本颜色纷歧样的话，会怎样办，重写多个类？ .con-text1, .con-text2 ... ?
 明显太不实际，也太甚冗余，所以或许我们需求用的面向对象中一个主要的思绪--抽像公共接口。或许我们可以这么做：
 
    .normal-text {
        padding: 8px 10px;
        background: red;
        border: 1px solid #ccc;
    }
    .red {color: red}
    .blue {color: blue}
        ...
    <p class=\"normal-text red\">test1

    <p class=\"normal-text blue\">test2

  是的，如许做没错，并且很好，可是慢着，假如我们还要要求每个p不只文本颜色纷歧样，布景色也纷歧样。。。怎样办？有人会想，我们照上面的思绪持续抽象就好了。比方：

    .normal-text {
        padding: 8px 10px;
        border: 1px solid #ccc;
    }
    .bg-red {background: red}
    .blue {color: blue}
    <p class=\"normal-text bg-red blue\">test

 
我们持续纠结下去，我们要border也分歧，甚至padding也分歧，怎样办？还持续别离吗？假如我们钻个牛角尖，我们对css进行彻底的别离，最终的后果会满是相似于
    .bg-red {background: red}
    .blue {color: blue}
    .pad-t8 {padding-top: 8px}
    .pad-l10 {padding-left: 10px}
        ...
  最终的后果就不是面向对象了，而是面向属性了...是的，别离的越彻底，开拓时的效率会越高，css文件也会越小越精简。可是别忘了如许做的结果是能够一个元素需求写5个，甚至10个并列的css类名去衬着...
 那如许，我们所谓的“类”意义安在，如许又和写style内联款式有什么辨别？我们维护时是不是要在html文档里满篇去找要几十上百个类名去增删改？？
 所以css别离是好的，可是过度的别离是不可的。若何掌握标准和权重才是最主要的。不才有几个小建议。
  1.css面向对象请面向通用的对象。比方box，一个网站可以有多个box款式，boxA，boxB...boxF...等等，对应呼应的boxA-tit,boxB-tit...等等，为这些通用的对象抽离公用的款式
  2.可认为全站都通用的款式进行抽离：比方肃清浮动
  .clearfix:after {
   content: \".\";
   display: block;
   height: 0;
   clear: both;
   visibility: hidden;
  }
  /* Hides from IE-mac \\*/
  .clearfix {zoom: 1;}
  /* End hide from IE-mac */
  3.可认为栅格化的结构款式做抽离， 如：col-a{width：..}, clo-b {width: ..}等等
  4.需求的时分部分的面向属性的绝对别离也是可以的，但请在有需求的时分部分运用。
  5.建议class的并列类名不要大于3个，不然就需求思索能否应该略微聚合一下了。
 以上只是小我建议，每小我在项目或建站时碰到的需求能够都纷歧样，本人秉着“中庸”的心态去衡量css的别离与聚合很主要。
 
 【关于JavaScript】
  --优雅的js
  关于这个方面，人人评论的就比拟多了。我这里只举很简略的例子，比方我们要写一个幻灯片。思绪我们有了，先初始化，然后需求一个变换函数，能够我们还需求一些突变的结果，所以还需求一个突变的函数，最终我们还需求主动轮播。有了思绪，我们的代码能够大约会如许：

        function init() { //初始化
            ...
            pos();
        }
        function pos () { //每张图片轮换函数
            ...
            window.timer = setInterval(function(){anim()}, 20);
        }
        function anim () { //突变的函数
            ...
            if(finish) { //变换完毕
                clearInter(timer);
                auto();
            }
        }
        function auto () {
            setInterval(function(){pos()}, 4000);
        }
       
        /* init */
        init();

 如许的方法我们大约可以了解为一种进程式编码。当然如许的风险有良多，比方，变量名污染，模块化治理，多实例重用等等都是问题。所以它明显不敷优雅。我本人常用的方法：

        var slider = function () {
            var init = function () {
                ...
                this.pos();
            }
            init.protorype = {
                pos : function () {
                    //TODO
                },
                anim : function () {
                    //TODO
                }
                auto : function () {
                    //TODO
                }
            }
            return init;
        }();
        /* init */
        new slider();

 至于为什么会引荐这种结构函数/原型 的夹杂方法来构建，可以参考之前的“我所调查的类结构方法”以及“动态原型”扩展的文章。别的还有种抽象结构类的方法也是我挺喜好的

    var Class = {
        create: function () {
            return function () {
                return this.init.apply(this, arguments);
            }
        }
    };
   
    var slider = Class.create();
    slider.prototype = {
        init: function () {
            //TODO
        }
    }
    /* init */
    new slider();
   好了，文已至此，也差不多了，前端作为UED里的一个职位，干的是编码的任务，注定了它的非平性，所以我们不得不说，正由于我们是前端，所以我们更需求“优雅”！！