Browsed by
分类:程序设计

编程命名中的7+1个提示

编程命名中的7+1个提示

前几天Neo写过《编程中的命名设计那点事》,这里也有另外一篇和程序命名的文章,可以从另一个角度看看。

1.- 变量应该是尽可能的望文知意。千万不要使用教材中的命名方式。

  • 好的变量 daysDateRange, flightNumber, carColor.
  • 坏的变量: days, dRange, temp, data, aux…

在我们的日常工作中,有很大数量的开发人员喜欢使用短的变量名,而不是有含义的变量名。这主要是因为我们大学教科书的那些示例所造成的,人都是先入为主,所以,教科书中的那些很抽象,带着演示的变量命名影响了我们一代又一代的程序员,并影响了他们很多年。虽然那些短的,教材式的变量名,可能会让你少打一些字,但其实,这是非常非常不好的。因为软件的维护成本远远大于了软件的开发成本,如果你不取一个好的一点的变量名,那么当进行代码评审时,当进行bug fixing时,当进行代码重构时,当进行代码维护时,你的某个变量名可能会让你一头雾水,不知道所措,还可以会让你走入陷阱,造成更大的时间成本。所以,一个可阅读的代码必然和那些不错的变量名分不开,而这也能让你的软件间接上有更好的质量。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (9 人打了分,平均分: 4.56 )
Loading...
优质代码的十诫

优质代码的十诫

1.- DRY: Don’t repeat yourself.

10commandementsDRY 是一个最简单的法则,也是最容易被理解的。但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事)。它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。

DRY 这一法则可能是编程届中最通用的法则了,目前为止,应该没有哪个程序员对这一法则存有异议。但是,我们却能发现,一些程序在编写单元测试(unit testing)时忘记了这一法则:让我们相像一下,当你改变一个类的若干接口,如果你没有使用DRY,那么,那些通过调用一系例类的接口的unit test的程序,都需要被手动的更改。比如:如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法,而是每个test case自己去构造类的实例,那么,当类的构造函数被改变时,你需要修改多少个test cases啊。这就是不使用DRY法则所带来的恶果。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (16 人打了分,平均分: 4.88 )
Loading...
编程中的命名设计那点事

编程中的命名设计那点事

在我开始设计系统的时候,我会花去很多时间去设计命名,因为好的命名和好的设计是分不开的。

In the beginning was the Word, and the Word was with God, and the Word was God
太初有道。道与神同在,道就是神。 (约翰福音第一章,第一节)

在设计过程中给类,方法和函数好的命名会带来好的设计,虽然这不是一定成立,但是如果坏的命名那一定不会给你带来好的设计。在设计过程,如果你发现你很难命名某一个模块,某个方法时,可能你真正遇到的问题不是难命名的问题,而是这个设计是否真的合理,你或许应该花更多的时间来重新设计一下你的模块。

好的命名不仅会带来好的设计,好的命名还提高了程序的可读性,降低代码维护的成本。另一方面,如果糟糕的命名会给代码带来一堵无形的墙,让你必须深入代码去研究代码具有的行为,增加你理解代码的时间。

为此我总结了几条关于命名的指导原则,希望这几条原则能为你的命名设计带来帮助,我使用的是C++的语法,当然这些原则也很容易扩展到其他语言中去。

类型命名(类,接口,和结构)


名字应该尽量采用名词
Bad:           Happy
Good:          Happiness

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (23 人打了分,平均分: 4.57 )
Loading...
菜鸟学PHP之Smarty入门

菜鸟学PHP之Smarty入门

  刚开始接触模版引擎的 PHP 设计师,听到 Smarty 时,都会觉得很难。其实笔者也不例外,碰都不敢碰一下。但是后来在剖析 XOOPS 的程序架构时,开始发现 Smarty 其实并不难。只要将 Smarty 基础功练好,在一般应用上就已经相当足够了。当然基础能打好,后面的进阶应用也就不用怕了。
  
  这篇文章的主要用意并非要深入探讨 Smarty 的使用,这在官方使用说明中都已经写得很完整了。笔者仅在此写下一些自己使用上的心得,让想要了解 Smarty 却不得其门而入的朋友,可以从中得到一些启示。就因为这篇文章的内容不是非常深入,会使用 Smarty 的朋友们可能会觉得简单了点。
  

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (2 人打了分,平均分: 4.50 )
Loading...
C语言下的错误处理的问题

C语言下的错误处理的问题

下面是三种C语言的错误处理,你喜欢哪一种?还是都不喜欢?

/* 问题: 不充分,而且很容易出错,前面成功分配的资源,后面出错需要帮助释放 */
int foo(int bar)
{
        int return_value = 0;
        int doing_okay = 1;
        doing_okay = do_something( bar );
        if (doing_okay)
        {
                doing_okay = init_stuff();
        }
        if (doing_okay)
        {
                doing_okay = prepare_stuff();
        }
        if (doing_okay)
        {
                return_value = do_the_thing( bar );
        }
        return return_value;
}

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (5 人打了分,平均分: 4.40 )
Loading...
一个排序算法比较的网站

一个排序算法比较的网站

下面这个网站是一个非常丰富的排序算法的网站。

Sorting Algorithm Animations
http://www.sorting-algorithms.com/

这是一个非常不错的排序算法的网站,当你打开这个网站的时候,请不要因为看到很多个图片的大红叉而鄙视它。你先点击网页上方的Problem Size,选择一个尺寸,20,30,40还是50,都行,于是你就可以看到下面整个大表中有图片显示出来了。如下所示:

sort

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (15 人打了分,平均分: 5.00 )
Loading...
深入浅出单实例Singleton设计模式

深入浅出单实例Singleton设计模式

单实例Singleton设计模式可能是被讨论和使用的最广泛的一个设计模式了,这可能也是面试中问得最多的一个设计模式了。这个设计模式主要目的是想在整个系统中只能出现一个类的实例。这样做当然是有必然的,比如你的软件的全局配置信息,或者是一个Factory,或是一个主控类,等等。你希望这个类在整个系统中只能出现一个实例。当然,作为一个技术负责人的你,你当然有权利通过使用非技术的手段来达到你的目的。比如:你在团队内部明文规定,“XX类只能有一个全局实例,如果某人使用两次以上,那么该人将被处于2000元的罚款!”(呵呵),你当然有权这么做。但是如果你的设计的是东西是一个类库,或是一个需要提供给用户使用的API,恐怕你的这项规定将会失效。因为,你无权要求别人会那么做。所以,这就是为什么,我们希望通过使用技术的手段来达成这样一个目的的原因。

本文会带着你深入整个Singleton的世界,当然,我会放弃使用C++语言而改用Java语言,因为使用Java这个语言可能更容易让我说明一些事情。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (6 人打了分,平均分: 4.50 )
Loading...
读后感:真正编程的力量

读后感:真正编程的力量

读到 coding horror (不知道中文翻译是什么,“代码恐慌”?) 中的文章 Real Ultimate Programming Power

文中讲到了软件开发中的方法论和其的演化,但是最让人觉得有意思的是两个引述:

The majority of developers do not suffer from too much design patterns, or too much SOLID, or agile, or waterfall for that matter. They suffer from whipping out cowboy code in a pure chaos environment, using simplistic drag & drop, data driven, vb-like techniques.

翻译: 让大多数软件开发者痛苦的,不是过多的设计模式,过多的SOLID(见注解), 过多的敏捷开发,或者瀑布模型;让大多数开发者痛苦的是在混乱的环境中用低级方式除去代码仙人留下来的古怪代码(好吧,这是我对cowboy code的曲解)。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (4 人打了分,平均分: 3.50 )
Loading...
101个设计模式

101个设计模式

所以设计模式,实是是一种方法,一种为了解决某种或某类物定问题所使用的设计模型。据说,在编程语言方面有100多种设计模式,而在现实生活中,传说有上成千上万个模式,比如写书有写书的设计模式,写武侠的一种,言情的另一种,连官方的新闻稿件也有。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (14 人打了分,平均分: 3.36 )
Loading...