Homejunk第三次总结与囚猴困境

(同上,本文避免关键字)

       在计算机软件发展的最初阶段,软件往往逻辑简单,用一些基础的汇编语言就可以轻松的实现所有需求。但是随着计算机处理能力不断提升,软件的复杂度也大幅度提升。为了解决汇编语言编程中遇到的种种不便,人们发明了各式各样的高级语言。但是在这一阶段,受限于存储设备与处理器能力,程序的规模不会很大,更不会出现需要多人协作完成,或者反复修改软件需求的情况。但即使使用了高级语言,当程序规模较大时,代码维护与多人协作仍困难重重。此时,人们开始逐渐注重规格化与标准化编程中的重要性。通过引入这一机制,可以使程序员更好地理解代码的含义,可以在不阅读别人的代码的情况下就能使用其所提供的功能。

规格bug

1

JSF位置错误

全体代码(大概1000行吧,没查过)

2

我也不知道算哪类

80行

原因

第一次的bug是从群里看的,助教说注释可以写在函数前面。可能对方的群里没这么说吧。我也不爱浪费时间和别人争。这也是为什么我从来不给别人找bug的原因。

第二次对方以此为由给我报了个Incomplete类的bug,我代码里全部JSF都是乱写的,拿来挑理我毫无异议。

5个前置条件不好写法及改进

1.前置条件必须是布尔表达式

  @ REQUIRES:time is long type;   改:time == long type;

2.前置条件需要更具体

public void randomMove() {

/** @ REQUIRES:None;    改:nowP.x>=0 && nowP.y>=0;

3.前置条件需要具体,不仅要考虑数据合法性,还要考虑空指针的问题

public long sleepTimeCaculate(long t,int s) {

/** @ REQUIRES:None;      改:t!=null && s!=null;

4.考虑需要用到的某些属性是否已经被初始化

/** @ REQUIRES:None;  改:maps != null;

5. 对于数组,要对整个数组的合法性做判断;

/** @ REQUIRES:code is valid;  改: 0=<i<=99 => 0<=code[i]<=99;

五个后置条件不好写法及改进

a)使用自然语言。

public static void fileWriter(String file,String str){

        /**

         * @REQUIRES: 

         *         file!=null;

         *         File(file).exist;      

         * @MODIFIED:  File(file);

         * @EFFECTS:  write str to end of File(file);

         */

    改进写法:

public static void fileIn(String fileName,String str){//写字符串str写到文件File(fileName)中

        /**

         * @REQUIRES: 

         *         File(fileName).exist==true;      

         * @MODIFIED:  File(fileName);

         * @EFFECTS:  File(fileName)!=\old(File(fileName));

         */

    b)后置条件为布尔表达式,不应用‘=’。

 public boolean getArrived(){

         /**

             * @REQUIRES:None;

             * @MODIFIES:None;

             * @EFFECTS:\result=this.arrived;

             */

    改进写法:

 public boolean getArrived(){

         /**

             * @REQUIRES:None;

             * @MODIFIES:None;

             * @EFFECTS:\result==this.arrived;

             */

    c)后置条件表述不清晰。

void setReachable() {

        /**

         * @REQUIRES:

         *         map!=null;

         * @MODIFIES:

         *      \this.reachable;

         * @EFFECTS:

         *      (\all point p;point q.reaches(q)||p.reaches(q);reachable[p.x][p.y].contains(q);

         */

    改进写法:

void setReachable() {

        /**

         * @REQUIRES:

         *         map!=null;

         * @MODIFIES:

         *      \this.reachable;

         * @EFFECTS:

         *      (\all point p,q;q.reaches(q)==true&&p.reaches(q)==true;reachable[p.x][p.y].contains(q)==true

         *                                      &&reachable[q.x][q.y].contains(p)==true;

         */

    d)使用自然语言。

String SPFA(point src,point des,Vector<point>[][] reachable) {       

     /**

         * @REQUIRES:src!=null&&src.inMap==true;

         *             des!=null&&des.inMap==true;

         * @MODIFIES: None;

         * @EFFECTS:\result==String(shortest path from src to des);

         */

    改进写法:

String SPFA(point src,point des,Vector<point>[][] reachable) {

        /**

         * @REQUIRES:src!=null&&src.inMap;

         *             des!=null&&des.inMap;

         * @MODIFIES: None;

         * @EFFECTS:\result!=null&&\result.length()>=0;

         */

    e)未书写exception_behavior。

void initMap(String name,TaxiGUI gui) {

         /**

         * @REQUIRES:

         *      name!=null;

         *      gui!=null;

         *      File(filename).exist;

         * @MODIFIES:

         *      \this.map;

         *      \this.numMap;

         * @EFFECTS:

         *      \all int i;0<=i<80;this.map[i]==readLine(name);

         *      !MapReadSucceed==>output error information

         */

    改进写法:

void initMap(String name,TaxiGUI gui) {

         /**

         * @REQUIRES:

         *      name!=null;

         *      gui!=null;

         *      File(filename).exist;

         * @MODIFIES:

         *      \this.map;

         * @EFFECTS:normal_behavior

         *                 \all int i;0<=i<80;this.map[i]==readLine(name);

         *                  !MapReadSucceed==>exceptional_behavior (WrongFormatException);         

       */              

被报的功能bug与规格bug聚集关系

无。

体会

(这回之所以能写这么多,是因为调研的时候不小心多调研别人作业一部分)

我觉得与其浪费时间被强制写现在看来没有意义的规格,不如多让人想一想那些几万行、几十万行的大项目是怎么写的,复杂的技术(光线追踪或者其他方面)是怎么实现的。

反正无论是我目前看过的项目(最小六万行、最大没查过),还是自己实现的万级以上的代码,均没觉得一个用如此严谨的逻辑式表达的代码存在的意义。无非最多是像用来作为sdk的代码注释很工整。至少我在使用别人的代码时,只要了解整体的功能与像样的函数名或注释就能猜出人家是怎么实现的。与其像这样费尽心思理解别人代码,不如去好好构架自己的代码的结构。

无论是JSF规格也好,还是就程序正确性判定也好,单纯摆出这么空且无意义的要求有意思么?实际中有人会在意出租车晚到1毫秒么?实际中有人会注意电梯晚了2毫秒么?把这些原本应该用来处理实际情况的问题的结果用这种要求来限定有意义么?看我们这些菜鸡互啄有意思么?无非就是浪费时间而已。至少我并不愿意花时间去争那几个分数,我也从来不认可用数字评判的能力。

不过话说回来,我就恰好第一时间看了最后一次作业的评测结果。对面的人也真是我难理解的大神级人物吧。单靠眼睛就能给我报5个功能相关的bug。我也特别想认识认识并且请教一下:搜索工具会用么?执行不消耗时间的量子计算机好用么?向量的点乘叉乘能判断方向知道么?

关于囚猴困境

(与博弈无关)

    囚徒困境之所以能成为一个博弈的问题,是因为每个人都会努力争取制定规则的人所认为的利益。然而随着人数的增长,并不是每个人会以这为自己的利益去不择手段。从另一个方面思考一下,一些观点可能对那些按着规则努力拼搏的人有帮助:

        1.人是自由的,除了无法突破的自然法则之外可以不听从任何规则。

        2.制定规则并让人听从的能力(也就是权力)是听从规则的人赋予的。

        3.现在的状况就是几个人高高在上看着一群猴在掐架。 

这便是囚猴困境与囚徒困境的差异。

以上。

猜你喜欢

转载自www.cnblogs.com/s-xx/p/9112530.html