我是看了http://expert.csdn.net/Expert/topic/2278/2278586.xml?temp=.858288
后发了这个贴子,欢迎大家提出你的观点!!
   我写代码从来不用高深的方法,能用简单的就简单的,实在不行就得用了,为什么呢?
   道理很简单,项目不可能由一个人做,做完后往往就交给一个维护,试想一下你写的代码不易懂,维护人的工作是多么的困难呀,还有就是对于人员流动频繁的公司就应是如此,一个人走了他的代码就交给下一个人维护,如是下一个看不懂上一个人的代码,这将会带来多大的损失呀。   致于哪些一味追求高深写法的人,我是经理的话第一个就开除他,中国的程序员就是这样个个都有高手,但写的软件都很烂,我想就是这个原因吧!

解决方案 »

  1.   

    一般在两种情况都能实现的话,我会看它的执行效率,差距不会很大我不会采用高深的写法,那样的话以后其他人维护起来都是问题,没有那个必要,不过这对初学者这样做比较好!HOHO个人看法!大家继续!!!!
      

  2.   

    举个例子,相信大家都做过mime base64的编码和解码函数吧。网络上也有很多,写得很清晰,很容易懂,但是你和Outlook对比运行一下,就知道效率有多差了。
    在这样的情况下,我们就不能光考虑可读性了。Adners用汇编写的Object Pascal编译器,我们不也一直用吗?呵呵,要是用c++写一个,速度肯定不是这个样子的。
      

  3.   

    复杂问题简单化,书写代码简练易懂化,是一个程序员应具备的基本素质
    一个真正的程序员不仅仅是一个 coding fan
      

  4.   

    呵呵,同意搂住的观点。
    代码是大家看的。没有必要搞那么复杂,而且有时觉得,代码简单些,效率不一定低,再者,有利于维护。也有这种同感:在解决一个问题的时候,绕来绕去,其实就是把问题看得太复杂了。刚刚看了另一个贴子(搂住提到的那个),大家都一味的赵好的决绝办法,可是就是没有想到用KeyDown,呵呵,他至少比KeyPress在这方面强一些(个人体会)。
      

  5.   

    我说楼主你未免小气了一点,
    http://expert.csdn.net/Expert/topic/2278/2278586.xml?temp=.858288
    就这个问题来开个帖,还给大家发个消息,有必要吗?我还是那句话:
    仁者见仁,智者见智;每个人都有自己的习惯,有自己的看法;正所谓青菜萝卜、各有所爱,
    大家在这里说自己的好,说别人的不好,未免强人所难了;
    当然,你有好的经验,说出来,让我辈菜鸟学习,那当然很好,但像这样、在前面这个贴子的前提下来讨论,我看很容易伤了兄弟们的和气。
    呵呵,想到什么就说什么,还望楼主海涵。
      

  6.   

    中国的程序员就是这样个个都有高手,但写的软件都很烂
    和这个原因有关系吗??
    我想和严谨与否和做软件的方法有关系,作软件是讲合作的,将技巧的,多少年前到现在,咱学习人家的管理技术,经销技术,现在学习人家做软件的方法。。怎么说呢,如何要求,如何做软件,才能将软件作的好,这个东东有时候和个人的技术没有太大的关系吧,听说日本的详细设计作到最后写代码的工作连一个高中生也能完成。好像扯远了
    桂秋兄估计很郁闷,好不容易有个卖弄技巧的机会。。hoho
    桂秋兄你当上斑竹没有,你答应我当上以后给偶10000可用分的,还没有对虾哈
      

  7.   

    同意楼主!!!
    平平淡淡才是真,从delphi 1.0用到现在6.0,我一向坚持少用构件,特别是第三方没有源码的
    自己的程序少用dll
      

  8.   

    To  wdsimon(老王(路漫漫其修远兮,吾将上下而求索)) 
       没有呀,我只是想听听大家的想法,大家可以畅所欲言,版主不要删除就是了!
      

  9.   

    agree : zjqyb(风清扬*任它溺水三千,我只取一瓢饮*) ( ) 
    没有代码的东西是不太放心。
    有代码的我基本上都要把原代码看懂才用的,
    不然出问题怎么办。
      

  10.   

    晕死了呵呵。用不用KeyPress也会招致这么大规模的“讨论”,不知道大家自己看过原来那个问题没有。我想首先明确的、并抱歉的告诉一些人,用KeyPres或者KeyDown是不能那么简单的实现该功能的。原因是什么呢,很简单,按下一个键后会如何改变编辑框的内容的长度这个问题——不是一个简单的Length(Edit1.Text)可以搞定的。因为编辑框中可能有部分内容别选择,那么按下一个键后,原来选中的内容会被替换;而且还有很多特殊键的问题,如Del、Ctrl+V、BackSpace。难道有人愿意用大量的if语句去作复杂的判断吗?不同意的可以自己动手写一下,看你能不能用KeyPress或者KeyDown用比较简洁的代码实现此功能。
    孰为复杂、孰为简单,难道不是一目了然么?海天子兄发消息让我来回复此贴,我委实觉着有些无聊了,呵呵。—————————————————————————————————
    宠辱不惊,看庭前花开花落,去留无意;毁誉由人,望天上云卷云舒,聚散任风。
    —————————————————————————————————
      

  11.   

    上面那个问题,本质不是使用KeyPress还是使用Perform发送消息的问题,而是选择KeyPress事件还是Change事件的问题,我想很多人高错了吧!—————————————————————————————————
    宠辱不惊,看庭前花开花落,去留无意;毁誉由人,望天上云卷云舒,聚散任风。
    —————————————————————————————————
      

  12.   

    TO lxpbuaa(桂枝香在故国晚秋)兄    我并不是针对前面贴子的内容而开这个贴,而是看到有兄弟讨论到这个问题了,其实很久以我就有这个想法讨论一下,今天刚好!希望大家能各抒己见,谁都没对错!
        同时活跃一下这里的气氛!哈哈!!
      

  13.   

    好热闹。我觉得还是解决问题重要,如果问题还没有得到解决,就讨论好坏,呵呵那个帖子,支持使用key事件的的确还没有给出解决方案,如果有了解决方案才好比较。哈哈,有些偏向 lxpbuaa(桂枝香在故国晚秋)
      

  14.   

    简简单单就是最好的了, 明明可以用hello world式的方法把问题解决,为什么非要写一个让盖茨都看不懂的程序来解决问题?
      

  15.   

    不会吧,我呆过几家公司,基本上维护原来的代码都不难。。((虽然有的注释不多,构架说明还挺细的,,看看就全OK了。。(((再讲现在写数据库的也用不上什么太牛B的算法。,理清表之间的关系就差不多了。
      

  16.   

    能够用简单的最好用简单的。这样便于维护。不求代码的简练,只求执行的效率。有的时候代码简单,效率很低。
    能够不用API的时候尽量不用。因为有的API用的不好,会出现莫明的错误。
    我不怕被人笑代码幼稚管用就行。当然提倡总结一个经过长期测试,而且功能明确的代码。
    条条道路通罗马,我喜欢大多数人走的路。
      

  17.   

    我不同意lxpbuaa(桂枝香在故国晚秋)的方法,虽然最后是调用了上面消息处理的方法,
    但是却牺牲了兼容性,可读性,在Linux下肯定不能用!!!
    有的时候编程序就像做人一样,不能太直接,应有所保留,含蓄一点,处理起来有很多灵活性!!!
    procedure TForm1.Edit1Change(Sender: TObject);
    begin
      with TEdit(Sender) do
        if MaxLength=Length(Text) then
          SelectNext(TWinControl(Sender),true,true);
    end;
      

  18.   

    楼主说的是在完成相同功能的情况下,要是代码功能都实现不了,还就不存在这个前提了。简单的方法肯定比复杂的方法好。但是如上面几位说的那个 KeyPress 之类的(具体情况我不是很清楚)但是,如果使用一堆 If 来处理的话,不能说是一个简单的方法,而是一个愚蠢的方法。简单的另一层含义就是巧妙。
      

  19.   

    本来近段时间不打算回帖了,但看了楼主的消息,觉得还是发表一下自己的意见!软件的完善、功能的好坏并不一定体现在代码量上!关键是团队开发各成员能在一段时间的交流、磨合之后形成相互工作的默契,在此基础上形成良好的风格、规范!试想,一个开发部如果能达到代码分辨不出是谁的风格,这才是真正的合作默契!至于采用通用易懂,还是难以理解,我认为并不是难以理解!而是各个人对开发工具使用的熟练程度决定了个人的水平问题!我一直用Delphi,如果对VCL比较熟悉的话,我想就不存在难以理解的代码了!程序员都希望自己的代码能够经典,所以我倒是觉得自己比较喜欢“难以理解”的代码!呵呵,从小语言表达能力比较次,兄弟们将就一下!
      

  20.   

    zjqyb(风清扬*任它溺水三千,我只取一瓢饮*)的方法好,哈哈,如果早出来就不用讨论了
      

  21.   

    呵呵,光看题目毫不犹豫的选择简单但是过去看了看那个引发这个话题的贴子想了很多
    确实,同样的功能,不同的写法,这之间的差别到底在哪里?我想如果是我的话,我也会用简单的那种方法我在做程序的时候,首先考虑的是自己别太累了能用简单方法实现的,为什么要用复杂的呢?但是如果使用了复杂的方法,别人会觉得你很高深莫测,确实也有种自豪感这个之间确实是有些矛盾的呵呵,所以,程序是给自己做的话,尽量用最简单的方法在CSDN上回答问题的话,能用复杂的就用复杂的,这样顺别自己提高,也能让问问题的人从另一个角度学到新知识还让别人觉得自己很高深,哈哈哈道理就象穿衣服,在家里传短裤拖鞋,出门西装革履 :)
      

  22.   

    我没有时间仔细看,
    不过做程序来看,当然要取简单的方法
    特别是delphi
    不是有那么一句话么?
    “真正的程序员用c,聪明的程序员用delphi”
    :)
    up一下
    顺便来这里看看
    http://expert.csdn.net/Expert/topic/2265/2265856.xml?temp=.9416315
      

  23.   

    大家继续讨论,其实这个问题没有必要讨论,讨论也讨论不出什么结果,如果你的项目经理容忍能力比较高,对你写出的缺少API的代码可以容忍,那是你的幸福;反过来,如果你的项目经理自己就不倾向写大量使用API的程序,那么你写出的大量使用API的程序就可能要受到排挤!其实前面那个问题已经没有讨论的必要,只不过讨论过程中有引发了其他一些话题,所以才有此帖的产生,楼上某些朋友没有必要在这里对楼主进行评判,不想参加自然不参加就可以了!我曾经看过一个人写的一个程序的源代码,使用API的量几乎可以占到全部程序函数调用的80%,至少是这个数,但这个人写的一个类似Visio的程序却在CSDN的首页上悬挂了快半年时间。我想这本身就是对程序的一种认可!但我还是那句话,我不倾向于丢弃IDE给你提供的库而去搞大量的系统API进来。当然,取决于个人风格!学习的人是应该多接触API,但具体做开开发以后,尤其是团队性质的开发,重要的一点就是大家的代码风格的一致性,可理解性和可维护性,这些都很重要。因为你已经是开发团队的一个成员!好比现在大家都写ADO应用,但有几个人可以放弃ADO去专门使用OLE-DB的API,我看没有多少人使用!原因很简单,本身用起来就不方便!同时,前面一位朋友提到的兼容性也需要考虑,或许Borland在Delphi和Kylix中对两种系统提供的不同名称的API进行封装后的函数和参数名称都是相同的,如果这个时候使用API我看未必就是一个什么好的事情了!移植能力明显下降!很多人在写代码的时候不善于使用Self或者Sender等参数,其实也和这里一样,降低可移植性,同时理解程度基本不变!
      

  24.   

    不说这个了,今天翻译了一篇文章,是原Delphi总设计师Anders Hejlsberg谈C#设计过程的,有兴趣的朋友可以看看:http://expert.csdn.net/Expert/topic/2282/2282106.xml?temp=.886944—————————————————————————————————
    宠辱不惊,看庭前花开花落,去留无意;毁誉由人,望天上云卷云舒,聚散任风。
    —————————————————————————————————
      

  25.   

    俺的项目经理本省就不喜欢用api函数,因为我们公司的员工,工作经验都不怎么多,
    所以如果写一大堆api函数的话,谁能看懂,谁能维护??
      

  26.   

    无话可说~~~~~~~~~~~~~
    每个人说的都有点道理~~~~~~~~~在一个项目中,很重要的是要考虑到TEAM
    我们是一个TEAM难以理解的方法实现好还是用通用易懂
    要看在什么情况下?有时关让别人能看懂,也是比较难的,每个人的水平不一样
    速度,效率都很重要,你不可能做得很完美很难说哪一种做法好;只有一个可以说:
    那就是老板
      

  27.   

    我不完全同意海天子大哥的意见,
    在做平常的一般项目的时候这个说法还是完全行的
    但是精巧的方法是非常重要的
    同样的生产线设备,同样的工具,我们却生产不出同样的零件,
    同样是0.1X微米技术,我们所谓的什么国产CPU却远远赶不上INTER等公司的,其实这在设计方法技巧上是有关系的