我的毛病,也是很多程序员的通病

nieyongxin 2000-08-16 08:41:00
我没有受过正规有效的编程教育,一切都是自己摸索着学习编程的,相信从计算机专业出来的也一样,我编程时编码很不规范,我自己的程序别人看懂很费劲,请问各大高手,有没有编码规范方面的资料和电子书籍!
...全文
1217 9 打赏 收藏 转发到动态 举报
写回复
用AI写文章
9 条回复
切换为时间正序
请发表友善的回复…
发表回复
gauss 2000-08-17
  • 打赏
  • 举报
回复
这是从一所外国大学网站上得到的文章,网址已经忘记了。
讲的是c++的命名法则,希望对您有点帮助。

Good Names
• Should fully and accurately describe the entity the variable represents
• Speak to the problem rather than the solution
• Use computed-value qualifiers (e.g. Ttl, Avg, Max, Min, Str, Ptr)
• Use opposites precisely

Good Names
• Give boolean variables names that imply True or False
• Use group prefixes when naming enumerated types
• Be leery of temporary variables

Names to Avoid
• Misleading names or abbreviations
• Names with similar meanings
• Variables with different meanings but similar names
• Names that sound similar
• Numerals in names
• Misspelled words
• Words commonly misspelled
• Names differing only by capitalization
• Names of library routines and predefined variables
• Names with hard-to-read characters
Why Have Conventions?
• They let you take more for granted
• They help you transfer knowledge across projects
• They help you learn code more quickly on a new project
• They reduce name proliferation
• They compensate for language weaknesses
• They emphasize relationships among related items
When You Should Have a Naming Convention
• When multiple programmers are working on a project
• When you plan to turn a program over to another programmer for modifications and maintenance
• When your programs are reviewed by other programmers in your organization
• When your program is so large that you can't hold the whole thing in your brain at once and must think about it in pieces
• When you have a lot of unusual terms that are common on a project and want to have standard terms or abbreviations to use in coding
Language-Independent Conventions
• Identify global variables (g_)
• Identify module variables (m_)
• Identify type definitions (_t)
• Identify named constants (_c)
• Identify enumerated types (_e)
• Identify input-only parameters in languages that don't enforce them (IP)
• Format names to enhance readability (mixed case, underscores)
Hungarian Naming Convention
• <prefix><base type><qualifier>
• Prefixes
– describes the use of the variable
– a (array), c (count), d (difference), g (global), i (index)
• Base Type
– data type of the variable being named
– wn (window), scr (screen), sz (null-terminated string)
• Qualifier
– the descriptive part of the name
– Page, Stitch, CurrentColor
Hungarian Naming Convention
• In addition to those shown in the text, the following are Hungarian Convention naming examples from Visual C++
– fArea
– sArea
– szName
– pDoc
– CMyDocument
– m_XPos
– iNumPages
Scope
• The extent to which your variables are known and can be referenced throughout a program
• limited scope known only in a small area
• large scope known in many places in the program
• Minimize scope
• Group references to a variable
Persistence
• The life span of a piece of data
– for life of block of code or routine
– as long as allowed
– for life of program
– forever
• Main difficulty
– assuming that a variable has a longer persistence than it really does
Binding Time
• The time at which a variable and its value are bound together
– when code written
– when code compiled
– when program loaded
– when program run
• Use latest binding time possible
Variable Use Guidelines
• Use variable for one purpose only
• Avoid variables with hidden meanings
• Make sure that all declared variables are used
Global Variables
• Accessible anywhere in a program
• Problems with use
– inadvertent changes
– aliasing
– re-entrant code
– code reuse
– modularity
Global Variables
• Reasons to use
– preservation of global values
– substitution for named constants
– streamlining extremely common data
– eliminating tramp data
Access Routines - Advantages
• Centralized control over the data
• Ensure all references are firewalled
• Get benefits of information hiding automatically
• Easy to convert to abstract data types
Access Routines - How to Use
• Require all routines go through the access routines for the data
• Don't just throw all your global data into the same module
• Build a level of abstraction into your access routines
• Keep all accesses to the data at the same level of abstraction
Numbers in General
• Avoid magic numbers
– exceptions: 0's and 1's
• Anticipate divide-by-zero errors
• Make type conversions obvious
• Avoid mixed-type comparisons
• Heed your compiler's warnings
Integers
• Check for integer division
• Check for integer overflow
• Check for overflow in intermediate results
Floating-Point Numbers
• Avoid additions and subtractions on numbers that have greatly different magnitudes
• Avoid equality comparisons
• Anticipate rounding errors
– use type with higher precision
– change to BCD
– use integers (one for whole part, one for decimal part)
Characters and Strings
• Avoid magic characters and strings
• Watch for off-by-one errors when indexing into a string
• String in C
– differences between string pointers and character arrays
– declare strings to have length CONSTANT+1
– initialize strings to null
– use arrays of characters instead of pointers
– use strncpy() instead of strcpy()
Boolean Variables
• Use boolean variables to document your program
• Use boolean variables to simplify complicated tests
• Create your own boolean type, if necessary
Enumerated Types
• Use for readability
• Use for reliability
• Use for modifiability
• Use as an alternative to boolean variables
• Check for invalid values
• Reserve the first entry in an enumerated type as invalid
Named Constants
• like a variable except that you can't change the constant's value once you've assigned it
• Use in data declarations
• Use instead of literals
• Simulate named constants with global variables (if necessary)
• Use named constants consistently
Arrays
• Check that array indexes are within the bounds of the array
• Think of arrays as sequential structures
• Check the end points of arrays
• Use subscripts of multidimensional arrays in the correct order
• Watch out for index cross talk
• Throw in an extra element at the end of an array
Pointers
• one of the most error-prone areas of modern programming
• consists of two parts
– a location in memory
– a knowledge of how to interpret the contents of the location
• Isolate pointer operations in routines
• Check pointers before using them
• Check the variable referenced by the pointer before using it
Pointers
• Use tag fields to check for corrupted memory
• Add explicit redundancies
• Set point to NULL after freeing
• Use extra pointer variables for clarity
• Simplify complicated pointer expressions
• Write routines to keep track of pointer allocations
• Draw a picture
• Free pointers in a linked list in the right order
• Use a nonpointer technique
Records and Structures
• Use to clarify data relationships
• Use to simplify operations on blocks of data
• Use to simplify parameter lists
• Use to reduce maintenance
Table-Driven Methods
• Table-driven method is a scheme that allows you to look up information in a table rather than using logic statements to figure it out
• Access methods
– Direct access
– Indexed access
– Stair-step access
• Table contents
– data
– a code that describes and action
– reference to a routine (function pointer)

Abstract Data Types (ADTs)
• A collection of data and operations that work on that data
• Advantages
– hide implementation details
– changes don't affect the whole program
– easier to improve performance
– program becomes more self-documenting
– removes need to pass data all over your program
– able to work with real-world entities rather than computer-science structures


DUKE_SOFT 2000-08-17
  • 打赏
  • 举报
回复
Give you a website, maybe you'll find it's useful.
http://www.umr.edu/~cpp/
Just like Onion said, it's like to do homework. Use them, your programs will be better.
元明 2000-08-16
  • 打赏
  • 举报
回复
关于规范的电子书籍我到是没见过,不过编程书中都会零散的说一些,你可以下载别人的源代码,或看随书所附光盘中的代码,你就能找到答案的.你用VC写程序吧!它的编辑器很好用的呦!
VictorYu 2000-08-16
  • 打赏
  • 举报
回复
我也一样,多看源码
www.codeguru.com
Ray_czh 2000-08-16
  • 打赏
  • 举报
回复
我想编程不规范的原因是由于你没有做好详细的需求分析,就开始动手做程序了。对于大的软件项目是一定要作好需求分析,才能开始编写软件的,否则后期的维护工作是很难进行的。
另外对与在写程序的过程中,良好的编程风格比编程技巧更加重要。要记住看程序的不会是你自己一个人。
Jackzhu 2000-08-16
  • 打赏
  • 举报
回复
程序编写规范


--------------------------------------------------------------------------------

在软件编程过程中,如果每个程序员都按自己的习惯和风格编写程序,这种因人而异的程序风格势必降低程序的可读性,对软件的测试、交流、重用以及软件的维护产生极为不利的影响。为了解决这个问题,最终提高开发效率,必须执行本规范。

本规范在编程基本风格、可读性、结构化、正确性与容错性、可重用性等方面提出了要求,它是程序员编程素质的综合体现。程序员的编程水平=编程规范+编程效率。

1.基本要求

1.1程序结构清析,简单易懂,单个函数的程序行数不得超过100行。

1.2打算干什么,要简单,直接了当,代码精简,避免垃圾程序。

1.3尽量使用标准库函数和公共函数。

1.4不要随意定义全局变量,尽量使用局部变量。

1.5使用括号以避免二义性。

 

2.可读性要求

2.1可读性第一,效率第二。

2.2保持注释与代码完全一致。

2.3每个源程序文件,都有文件头说明,说明规格见规范。

2.4每个函数,都有函数头说明,说明规格见规范。

2.5主要变量(结构、联合、类或对象)定义或引用时,注释能反映其含义。

2.7常量定义(DEFINE)有相应说明。

2.8处理过程的每个阶段都有相关注释说明。

2.9在典型算法前都有注释。

2.10利用缩进来显示程序的逻辑结构,缩进量一致并以Tab键为单位,定义Tab为 6个字节。

2.11循环、分支层次不要超过五层。

2.12注释可以与语句在同一行,也可以在上行。

2.13空行和空白字符也是一种特殊注释。

2.14一目了然的语句不加注释。

2.15注释的作用范围可以为:定义、引用、条件分支以及一段代码。

2.16注释行数(不包括程序头和函数头说明部分)应占总行数的 1/5 到 1/3 。

 

3.结构化要求

3.1禁止出现两条等价的支路。

3.2禁止GOTO语句。

3.3用 IF 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。

3.4用 CASE 实现多路分支。

3.5避免从循环引出多个出口。

3.6函数只有一个出口。

3.7不使用条件赋值语句。

3.8避免不必要的分支。

3.9不要轻易用条件分支去替换逻辑表达式。

 

4.正确性与容错性要求

4.1程序首先是正确,其次是优美

4.2无法证明你的程序没有错误,因此在编写完一段程序后,应先回头检查。

4.3改一个错误时可能产生新的错误,因此在修改前首先考虑对其它程序的影响。

4.4所有变量在调用前必须被初始化。

4.5对所有的用户输入,必须进行合法性检查。

4.6不要比较浮点数的相等,

如: 10.0 * 0.1 == 1.0 , 不可靠

4.7程序与环境或状态发生关系时,必须主动去处理发生的意外事件,如文件能否逻辑锁定、打印机是否联机等。

4.8单元测试也是编程的一部分,提交联调测试的程序必须通过单元测试。

 

5.可重用性要求

5.1重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。

5.2公共控件或类应考虑OO思想,减少外界联系,考虑独立性或封装性。

5.3公共控件或类应建立使用模板。
Areslee 2000-08-16
  • 打赏
  • 举报
回复
看一看软件工程方面的书就可以了
Wingsun 2000-08-16
  • 打赏
  • 举报
回复
你应该去看一些软件工程的书,在书店中有。
onion 2000-08-16
  • 打赏
  • 举报
回复
就和做作业一样,这也是个习惯,要在平时养成。专门的书没有,倒是一本南开的WINDOWS编程的书上有这方面的说明,较详细。

16,467

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧