当前位置:首页 > 天道酬勤 > 正文内容

女性优雅高贵的网名(优雅的女人)

张世龙2021年12月20日 19:43天道酬勤760

笔者认为,为了进行比较优雅的编码,需要按照以下限制进行排序。

关于好名清晰结构足够差的算法,说明如下。

好的命名

如果名字不对,语言不通,语言不通,事情就不好办了

孔子

孟子说:“孔子说得对。”

命名很重要。 逻辑学教材(读者感兴趣的话,在此推荐《逻辑学导论》 ) ) ) ) ) ) ) )中,长文讨论了命名问题。 我国古代,在人才辈出的百家争鸣时期出现了“名家”的学派。 专门讨论著名的“白马非马”“离坚白”等命名问题,笔者认为,尽管有时间阅读,但我国迄今为止出现了三个思想大解放时期。 一、春秋战国时期的百家争鸣,很遗憾被xfdxss的郡县制大一统终结了。 第二,民国时期,西方思想最先涌现,国民暴跳如雷,如梦初醒。 三、现在技术革命急剧降低了中央思想的控制力,让底层人民有了选择被谁控制思想的自由(请参考现在基于互联网的粉丝文化、圈子文化)。 所以,大家只有写好代码,才能不帮少年的忙哦。

回到主题,基于命名不怕长就不明确的原则,应该尽量明确一个类、方法、变量的含义,实际上笔者喜欢OC的方法(消息)命名规则。 例如:

(void ) buy:(nsstring* )从: ) nsstring* )存储日期* )时间;

虽然很长,但是很清楚。 下面详细说明名字。

接口命名

接口的命名一般是在前缀I上加上名词和形容词, Net Framewrok类库实际上就是这样做的。 例如,您可以:

system.collections.generic.I collection (名词) system.collections.generic.ienumerable )接口通常用于描述一个或多个行为

抽象类

抽象类通常不需要加前缀或后缀。 另外,有些yxddh喜欢根据需要给抽象类加Base后缀。 我觉得命名如下比较好。

Shape (抽象类) Ellipse (具象类) Rectangle )具象类

尽量使用名词,在不排除个别情况的情况下将一个行为封装到类中时使用动词。

方法

使用动词或动词性短语。

到此为止。 我觉得其他字段、属性、事件等的命名问题很少,所以停止讨论。 例如,有些人喜欢用下划线开始字段,有些人喜欢用m_开始字段。 哪个都行。 即使要求同样的事情,只要使用了恰当的语言,也不会添太多麻烦。 反而,只有制定了巨大而细致的规范,比如编辑需要时间,读者也记不住,即使读者记住了,也有可能因为与自己的习惯不同而产生抵触情绪等,才会有问题。

另外,必须强调不使用拼音而多用英语,不使用缩写而多用全名,尽量不使用拼音缩写,甚至在方言拼音缩写,甚至英语中使用拼音缩写……… 但是,也不能排除像“计划生育”这样难以翻译的单词用拼音使用。 需要明确术语表或进行维护。 另外,也并不是不能使用缩写。 一般的缩写形式,例如“Id”,不会引起误解,也可能有助于代码的清晰化。

因为英语水平的问题,毕竟我们的母语不是英语,所以不知道用什么单词是不可避免的。 此时,请尝试使用代码lf。 感谢网络工程师unbug开发的这个工具。 这个应该读作“kodf”吧,但倒数第二个字符不是I,而是l。

清晰的结构

基本要求

用关键字(如if、while等)括起来的表达式,哪怕只有一句,也要用大括号括起来,尽量避免使用直立人时代的goto语句过长的方法,将大方法分割为几个小方法,方法的功能尽量单一,尽量避免重复代码。 将其转移到公共工具上,尽量避免过大的类,分成几个类,在各自的职务上做适当的评论,评论过多,说明代码本身的表现力有可能得到加强。 虽然也有很难的逻辑,但是也可以写详细的评论。 如果不写评论的话,请注意辞职时不要漏了擦屁股的人自己的地址

熟悉以下常用的面向对象设计原则。

开放式-关闭单一职责陶醉的镜子更换依赖倒置接口隔离,要求更高

熟悉常用的设计模式:

方法抽象工厂发包人模式单一例模式适配器模式外观模式观察者模式指令模式代理模式面向对象语言的三个特点谁都知道,但真的很不容易使用。 三个特点只是面向对象设计的基础,在此基础上建设了面向对象的高楼。 笔者工作多年,感叹无为的岁月,但至今不熟悉面向对象设计的十分之五六。 笔者想强烈推荐Head First系列有名的作品《Head First 设计模式》这本书。 另外,这个网站很好。 简单地说,案例经典: www.oodesign.com。 另外,《Java编程思想》开头部分关于面向对象设计的说明也很棒。

使用成熟的设计模式有两个好处。

这些解决方案已经被尝试过,使用了即使无效也不会出错的设计模式的名称本来就是在程序员之间传播的概念,基于对共同概念的认识当然可以降低交流成本,代码的扩展性也很好要求熟悉常用的设计模式,可以得到其优点,避免其缺点。

需要注意的是,不要乱用设计模式。 只有在需求发生变化或预计需求会发生变化时,才能使用这些模式封装发生或可能发生的变化。 有

时候再重构代码时也会用到,比如外观模式和设配器模式等。

更高要求

能力越大,责任越大

──蜘蛛侠

大项目肯定不是一个人能完成的,人多了容易发生混乱,此时需要团队的领袖勇敢地承担起义不容辞的责任,包括但不限于:

定期维护代码框架、分层结构。写的时间长了难免乱,领袖人物要定期排除,及时消除臭味引导粗犷的刺猬们做代码审查。审查的意义不在于监督,而在于学习和维持良好的态度。学习指通过代码审查学习别人的长处,同时帮助别人进步。保持良好的态度是指如果预知了有人会看自己的代码,那么就会自觉地尽量把代码写工整,即使审查代码的人偷懒没有真真看过,正所谓,如果人人都相信三尺之上有神灵,那么也就没人做坏事了,宗教的积极意义就在于此,扯远了。过目数据库设计及时更新或委派组员更新文档

关于文档,还需多说一句:只有再非常有必要写文档的情况下才写文档。如果写了一大堆可有可无的文档,代码更新后文档也要及时更新,很难做到的。一个新手面临着一堆和代码脱节的文档只会起误导作用,以代码本身的表达力和口头交流为主,以文档交流为辅,两手都要抓,一只手硬,一只手软。

不十分差劲的算法

相信大部人做的项目都是性能不敏感的,只要稍稍注意就能做好。比如该使用分页的地方就使用分页,该根据条件查询数据库的就别一次都查出来,该优化数据库就优化数据库。

此外,压力测试也很有必要,有的性能问题只有在数据量大了的情况下才出现。很多性能问题都是到了生产环境中才暴漏出来的。

代码之外

和团队建设比起来,以上只能算是雕虫小技,只起到了一个锦上添花的作用。如何使团队保持活力,保持积极性才是最重要的,通常也是最容易被领导忽视的,最难做好的,这些已超出笔者能力范围和本文的论述重点,有机会再写。祝大家工作愉快!

扫描二维码推送至手机访问。

版权声明:本文由花开半夏のブログ发布,如需转载请注明出处。

本文链接:https://www.zhangshilong.cn/work/25832.html

标签: 抽象类
分享给朋友:

发表评论

访客

看不清,换一张

◎欢迎参与讨论,请在这里发表您的看法和观点。