设计程序时应遵循哪些基本原则（在设计程序时应采用的原则之一是）
今天给各位分享设计程序时应遵循哪些基本原则的知识，其中也会对在设计程序时应采用的原则之一是进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
代码设计时应遵循哪些原则
1提高编码质量，代码可读性和可维护性。
2代码编写规范
2.1删除所有无用代码
2.2必须给代码添加注释，一个类的注释字数不得小于代码的百分之20%
2.3建议遵循30秒原则。如果另一个程序员无法在三十秒内无法知道你的函数在做什么，如何做以及为什么要这样做，那么说明你的代码是难于维护的，需要得到提高。
2.4一个函数的代码长度不允许超过100行，超过一百行的函数建议在不破坏原子性的基础上进行拆分。
2.5变量都应在方法或者类的头部集中定义
2.6保证一行代码只做一件事
2.7使用括号来控制操作符的运算顺序，以免使用java默认的操作符优先级顺序。
2.8代码格式化：对代码进行格式化，再进行提交。
2.9接口不允许没有方法或者变量的声明
3.命名规范
3.1各种标识符的命名要使用有实际意义的英文单词或者英文单词缩写，缩写词及英文单词要收录在项目的简写词汇表中。切忌使用阿拉伯数字和拼音进行命名。
3.2类名：首字母大写，每个单词首字母都需要大写。
3.3方法名：首字母小写，其余单词首字母都需大写。
3.4全局变量，和常量名称要求全部字母大写。
3.5参数名称与局部变量基本相同，区别在于参数名称需要加上冠词a，an或者在单词结尾以s结束。
4.注释规范
4.1注释需要注意的事项：
★注释应该用中文清晰表达意思，应该是程序看起来更清晰，更容易理解
★注释要尽量简明，避免装饰性的注释。
★注释不但要说明做什么，还应当说明为什么要这样做。最好先写注释表明要做什么，再进行编码。
4.2类的注释
★类的用途，目的。包括其他人感兴趣的介绍。
★已知bug,当然最好是修改好所有的错误，但有时可能暂时没有办法修改，或者没有时间修改。
★开发和维护该类的历史列表，记录每一次修改的作者，日期，修改的内容。
★列举类的各种稳定状态，说明调用成员函数使类的状态产生的变迁(可选)。
★同步问题（可选）
★对主要的算法必须加以说明，主要流程必须给予引导性说明
标准格式：
如果对已经版本话的类进行了修改，需要按照如下格式为每一次修改附加修改历史记录：
//修改人+修改日期
//修改说明范例：
//李四2010/07/02
//添加错误数据修改后继续批量保存的处理函数saveBatch(
@Bind(key="itemParams",defaultValue="")StringitemParams,
@Bind(key="pid",defaultValue="")Stringpid)。
//王小二2010/07/02
4.3接口注释：
★接口的注释风格基本与类的注释风格相同；
★在别人使用接口之前，必须了解接口所包含的概念。检验一个接口是否应该定义的简单方法是：你是否能★够容易的描述接口的用途；
★接口如何应当和不应当被使用。开发者需要知道该接口如何被使用，也希望知道该接口不能被怎样使用。
4.4函数的注释
★函数头注释必须包括：函数执行了什么功能，为什么要这样处理；函数处理过程中对对象的哪些属性
★可能进行更改；函数执行前后，对象的状态；
★比较、循环等控制结构加注释（可选）；
★在代码的功能并非一目了然的情况下，应当说明为什么要这样做；
★局部变量必须加注释；
★复杂难写的代码必须加注释；
4.5类属性的注释:
★描述域的用途。使别人知道如何去使用它；
★对于有着复杂事物规则的域，可以加入范例来说明。有时候一个简单的小例子，抵的上千言万语；
程序中的设计模式设计都有什么原则呢？
你好，很高兴能回答你的问题。
程序软件开发中设计模式常用的的六大原则有下面几个：
1、开闭原则
开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
3、依赖倒转原则
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
5、迪米特法则，又称最少指导原则
最少指导原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则
合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。
工厂模式主要的意图是：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
案列1：您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。 2、Hibernate 换数据库只需换方言和驱动就可以。
优点： 1、一个调用者想创建一个对象，只要知道其名称就可以了。 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现，调用者只关心产品的接口。
缺点：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。
案例2：日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。 2、数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。 3、设计一个连接服务器的框架，需要三个协议，"POP3"、"IMAP"、"HTTP"，可以把这三个作为产品类，共同实现一个接口。
注意事项：作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。
希望能帮到你，谢谢！
设计程序时应遵循哪些原则
正确性.正确性是判断程序质量的首要标准.所谓正确性是指程序本身具备且只具备程序设计规格说明书中所列举的全部功能. 可靠性.可靠性是指程序在多次反复使用过程中不失败的概率. 简明性.简明性的目标是要求程序简明易读. 有效性.程序在计算机上运行需要使用一定数量的计算机资源,如CPU的时间,存储器的存储空间.有效性就是要在一定的软硬件条件下,反映出程序的综合效率. 可维护性.程序的维护可分为校正性维护,适应性维护和完善性维护.一个软件的可维护性直接关系到程序的可用性,因此应特别予以关注. 可移植性.程序主要与其所完成的任务有关,但也与它的运行环境有着一定的联系.软件的开发应尽可能远离机器的特征,以提高它的可移植程度.例如,用高级语言编写程序就比用汇编语言编写程序的可移植性好.
程序设计的三大原则
单一职责原则
软件需要做的内容有许多，比如一个在Unity中开发一个俄罗斯方块小游戏。其中将会有UI逻辑，游戏进度逻辑，消除方块逻辑，方块移动逻辑等等。我们在设计软件的时候就是要讲他们的职责相互分离，当你能够想到一个类有多于一个职责时就可以考虑将其分离出来。
开放-封闭原则
对于扩展是开放的，对于更改是封闭的。
将不变的部分作为基类，在更改需求的时候选择增加扩展类而不是修改原有类。
依赖倒转原则
抽象类不应该依赖细节，细节应该依赖于抽象。要针对接口编程而不是实现编程。
里式转换原则
只有当子类可以替换掉父类软件单位的功能不收到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
软件设计原则有哪些
七大设计原则
开闭原则
依赖导倒置原则
单一职责原则
接口隔离原则
迪米特原则
里氏替换原则
合成复用原则
设计模式-创建型模式
工厂方法模式
抽象工厂模式
建造者模式
单例模式
原型模式
设计模式-结构性模式
适配器模式
装饰者模式
代理模式
外观模式
桥接模式
组合模式
享元模式
设计模式-行为型模式
策略模式
模板方法模式
观察者模式
访问者模式
迭代器模式
责任链模式
中介者模式
解释器模式
状态模式
命令模式
备忘录模式
软件设计原则介绍
所以，可以说软件系统是连接需求分析、硬件系统以及使得系统实现的桥梁，对软件的设计应首先了解软件设计的设计原则。
设计原则
(1)可靠性
软件系统的规模越做越大越加复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，软件系统的可靠性也直接关系到设计自身的声誉和生存发展竞争能力。软件可靠性意味着该软件在测试运行过程中避免可能发生故障的能力，且一旦发生故障后，具有解脱和排除故障的能力。软件可靠性和硬件可靠性本质区别在于：后者为物理机理的衰变和老化所致，而前者是由于设计和实现的错误所致。故软件的可靠性必须在设计阶段就确定，在生产和测试阶段再考虑就困难了。
(2)健壮性
健壮性又称鲁棒性，是指软件对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。软件健壮性是一个比较模糊的概念，但是却是非常重要的软件外部量度标准。软件设计的健壮与否直接反应了分析设计和编码人员的水平。
(3)可修改性
要求以科学的方法设计软件，使之有良好的结构和完备的文档，系统性能易于调整。
(4)容易理解
软件的可理解性是其可靠性和可修改性的前提。它并不仅仅是文档清晰可读的问题，更要求软件本身具有简单明了的结构。这在很大程度上取决于设计者的洞察力和创造性，以及对设计对象掌握得透彻程度，当然它还依赖于设计工具和方法的适当运用。
(5)程序简便
(6)可测试性
可测试性就是设计一个适当的数据集合，用来测试所建立的系统，并保证系统得到全面的检验。
(7)效率性
软件的效率性一般用程序的执行时间和所占用的内存容量来度量。在达到原理要求功能指标的前提下，程序运行所需时间愈短和占用存储容量愈小，则效率愈高。
(8)标准化原则
在结构上实现开放，基于业界开放式标准，符合国家和信息产业部的规范。
(9)先进性
满足客户需求，系统性能可靠，易于维护。
(10)可扩展性
软件设计完要留有升级接口和升级空间。对扩展开放，对修改关闭。
（11）安全性
安全性要求系统能够保持用户信息、操作等多方面的安全要求，同时系统本身也要能够及时修复、处理各种安全漏洞，以提升安全性能。
简述程序设计的原则
结构化程序设计方法的主要原则可以概括为自顶向下，逐步求精，模块化，限制使用goto语句。
1．自顶向下：程序设计时，应先考虑总体，后考虑细节；先考虑全局目标，后考虑局部目标。不要一开始就过多追求众多的细节，先从最上层总目标开始设计，逐步使问题具体化。
2．逐步求精：对复杂问题，应设计一些子目标作为过渡，逐步细化。
3．模块化：一个复杂问题，肯定是由若干稍简单的问题构成。模块化是把程序要解决的总目标分解为子目标，再进一步分解为具体的小目标，把每一个小目标称为一个模块。
4．限制使用goto语句
结构化程序设计方法的起源来自对GOTO语句的认识和争论。肯定的结论是，在块和进程的非正常出口处往往需要用GOTO语句，使用GOTO语句会使程序执行效率较高；在合成程序目标时，GOTO语句往往是有用的，如返回语句用GOTO。否定的结论是，GOTO语句是有害的，是造成程序混乱的祸根，程序的质量与GOTO语句的数量呈反比，应该在所有高级程序设计语言中取消GOTO语句。取消GOTO语句后，程序易于理解、易于排错、容易维护，容易进行正确性证明。作为争论的结论，1974年Knuth发表了令人信服的总结，并证实了：
（1）GOTO语句确实有害，应当尽量避免；
（2）完全避免使用GOTO语句也并非是个明智的方法，有些地方使用GOTO语句，会使程序流程更清楚、效率更高。
（3）争论的焦点不应该放在是否取消GOTO语句上，而应该放在用什么样的程序结构上。其中最关键的是，应在以提高程序清晰性为目标的结构化方法中限制使用GOTO语句。
设计程序时应遵循哪些基本原则的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于在设计程序时应采用的原则之一是、设计程序时应遵循哪些基本原则的信息别忘了在本站进行查找喔。
