下载文档原格式
计算机二级考试《VFP》第三章复习重点2017计算机二级考试《VFP》第三章复习重点以下是店铺整理的2017计算机二级考试《VFP》第三章复习重点知识，希望对您的学习有所帮助!第三章数据与数据运算VISUAL FOXPRO的基本数据元素：(1) 常量、变量、表达式。
(2) 常用函数：字符处理函数、数值计算函数、日期时间函数、数据类型转换函数、测试函数。
1.常量常量是指在程序运行过程中始终不变化的数据，又称为常数。
在VFP 中常量可分为六种类型：2. 变量变量是在操作过程中可以改变其取值或数据类型的数据项。
在Visual FoxPro系统中变量分为字段变量、内存变量(简单变量、数组变量)2类。
此外，作为面向对象的程序语言，Visual FoxPro在进行面向对象的程序设计中引入了对象的概念，对象实质上也是一类变量。
确定一个变量，需要确定其三个要素：变量名、数据类型和变量值。
(1).命名约定使用字母，下划线和数字命名。
内存变量一般建议不采用汉字命名;命名以字母或下划线开头;除自由表中字段名、索引的TAG 标识名最多只能10 个字符外，其他的命名可使用1～128 个字符;避免使用Visual FoxPro 的保留字;文件名的命名应遵循操作系统的约定。
(2).字段变量字段变量是数据库管理系统中的一个重要概念。
它与记录一纵一横构成了数据表的基本结构。
一个数据库是由若干相关的数据表组成，一个数据表是由若干个具有相同属性的记录组成，而每一个记录又是由若干个字段组成。
字段变量就是指数据表中已定义的任意一个字段。
我们可以这样理解：在一个数据表中，同一个字段名下有若干个数据项，而数据项的值取决于该数据项所在记录行的变化，所以称它为字段变量。
字段变量的数据类型与该字段定义的类型一致。
字段变量的类型有数值型、浮点型、整型、双精度型、字符型、逻辑型、日期型、时间日期型、备注型和通用型等。
使用字段变量首先要建立数据表，建立数据表时首先定义的就是字段变量属性(名字、类型和长度)。
字符集及消对规则的定义简要说明;字符集和校对规则字符集是一套符号和编码。
校对规则是在字符集内用于比较字符的一套规则。
MySql在collation提供较强的支持，oracel在这方面没查到相应的资料。
不同字符集有不同的校对规则，命名约定：以其相关的字符集名开始，通常包括一个语言名，并且以_ci（大小写不敏感）、_cs（大小写敏感）或_bin（二元）结束校对规则一般分为两类：binary collation，二元法，直接比较字符的编码，可以认为是区分大小写的，因为字符集中'A'和'a'的编码显然不同。
字符集_语言名，utf8默认校对规则是utf8_general_cimysql字符集和校对规则有4个级别的默认设置：服务器级、数据库级、表级和连接级。
具体来说，我们系统使用的是utf8字符集，如果使用utf8_bin 校对规则执行sql查询时区分大小写，使用utf8_general_ci 不区分大小写。
不要使用utf8_unicode_ci。
如create database demo CHARACTER SET utf8; 默认校对规则是utf8_general_ci 。
Unicode与UTF8Unicode只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储.UTF8字符集是存储Unicode数据的一种可选方法。
mysql同时支持另一种实现ucs2。
详细说明:字符集(charset)：是一套符号和编码。
校对规则(collation)：是在字符集内用于比较字符的一套规则，比如定义'A'<'B'这样的关系的规则。
不同collation可以实现不同的比较规则，如'A'='a'在有的规则中成立，而有的不成立；进而说，就是有的规则区分大小写，而有的无视。
每个字符集有一个或多个校对规则，并且每个校对规则只能属于一个字符集。
MySQL数据库表和字段命名规范导言：在数据库设计和开发中，表和字段的命名规范是非常重要的。
一个良好的命名规范能够提高代码的可读性、可维护性和辨识度。
本文将介绍一些常见的MySQL 数据库表和字段命名规范，希望对读者在数据库开发中有所帮助。
一、表命名规范1. 采用小写字母命名表名。
这样可以避免在跨平台时大小写不敏感的问题，并且有助于代码的一致性。
2. 多个单词用下划线（_）分隔。
例如，user_info、order_detail等。
3. 尽量给表名取得有意义且具有描述性的名字，能够清楚表达出表所存储的内容。
二、字段命名规范1. 采用小写字母命名字段名。
同样，这可以避免大小写不敏感的问题。
2. 也可以使用下划线（_）分隔。
例如，create_time、user_id等。
3. 尽量给字段取得有意义的名字，能够清楚表达字段所存储的数据。
三、表和字段命名的一些约定1. 避免使用MySQL保留字作为表名或字段名。
在MySQL中有一些保留字（如select、update等），如果使用这些保留字作为表名或字段名，可能引发一些潜在的问题，在查询时需要特殊处理。
可以在命名中加上下划线或其他可辨识符号来避免与保留字的冲突。
2. 避免使用过长或过于简短的命名。
过长的命名可能造成代码的冗余，过于简短的命名可能不具备辨识度。
合理的命名长度可以提高代码的可读性和可维护性。
3. 避免使用缩写和简写。
虽然缩写和简写可以减少字符数，但是在团队协作中容易引起误解和混淆。
具有明确、清晰含义的命名可以降低开发和维护的成本。
4. 保持命名的一致性。
在整个数据库中，保持表和字段的命名一致性，可以提高理解和维护代码的效率。
例如，如果一个表的主键命名为"id"，那么在其他表中也保持主键命名为"id"，而不是使用其他类似"pk"或"key"的名称。
四、表和字段命名的示例以下是一些常见的表和字段命名示例，仅供参考，读者可以根据实际情况进行调整：1. 用户信息表：user_info（字段包括user_id, username, password, email等）2. 订单详情表：order_detail（字段包括order_id, product_id, quantity等）3. 商品信息表：product_info（字段包括product_id, product_name, price等）4. 地址信息表：address_info（字段包括address_id, user_id, address等）结论：良好的MySQL数据库表和字段命名规范是数据库开发中必不可少的一部分。
C语⾔命名规范⽰例⼀、命名约定——变量名（1）公共对象（变量）与公共函数（即具有全局性）应使⽤指⽰符作为前缀（即源代码⽂件）。
（2）所有对象均由字母、数字、下划线构成。
若是⽂件内部对象，只能采⽤⼩写字母。
若是全局对象（即外部链接）应加前缀。
（3）所有⽂件范围对象应在源代码⽂件中声明。
所有全局范围的对象应在头⽂件中声明。
定义类型适⽤的最⼩可能范围。
（4）对不同的或冗余⽂件将使⽤由下划线与单个字母组成的后缀（eg：tim_get_time_A.c，tim_get_time_B.c）。
（5）函数参数列表名称：函数内部的变量名应被维持⾄函数边界。
⼆、命名约定——函数名（1）函数名由字母、数字、下划线构成，尽量使⽤由单个动词和单个名词组成的名字。
（2）⾯向对象的相关函数应含有动词，后跟下划线与object_name（对象名）。
（3）函数名前缀”is”或”is_”应保留个布尔型函数以专门返回boolean_t等布尔型。
例如：isflower（）。
三、命名约定——常量名（1）声明（即单独⼀⾏⽆参数申明#define），利⽤类型限定如const的对象与枚举量将被指为常量。
（2）整型、字符型与浮点型常量命令，⽆论其使⽤范围，均可由下划线与字母构成：⼤写字母与数字，⼩写字母与数字并以”_k”为后缀。
（3）后缀”_k”被保留⽤于整型、字符型与浮点型常量命名（4）使⽤符号量代替⽂字提⾼代码的可读性与维护性例如：If（speed_value=234）可重写为：static const uint16 speed_max_k=234；If（speed_value=speed_max_k）；（5）枚举常量应由⼤写字母与下划线字符构成例如：typedef enum {BLACK,RED,GREEN} font_color_t；四、命名约定——宏名五、命名约定——类型别名类型别名的命名应由⼩写字母与下划线构成。
所有的类名应具有后缀”_t”（⾮union型）与”_u”（union型）。
动态连接库和符号(symbol)shared library (.so)"Program Library Howto-Shared Libraries"是很好的材料, 下面的内容多是据此整理的.定义:Shared libraries are libraries that are loaded by programs when they start.使用shared library(共享库)会有很多好处, 比如软件升级, 不难想象.命名约定:1. soname: 每个共享库都有一个soname, 形式为"libNAME.so.x", 其中x是版本号. 如"libc.so.6".2. real name: 真正的库文件, 一般形式为"soname.y[.z]", 即"libName.so.x.y[.z]", 其中y是minor number, z是release number, 是可选的. 如"libattr.so.1.1.0".3. linker name: compiler用来请求库时使用的名字, 一般是没有版本号的soname.放置位置& load/preload:共享库一般放在一些约定的目录下, 如/usr/lib/, /usr/local/lib, /lib/等. 这其实是遵循FHS的, 比如/usr/local/lib下放置的一般是用户开发的库.在启动程序时, program loader(ld-linux.so.x)会找到并加载程序需要的共享库, loader查找的路径一般就是上述的几个目录, 这些目录在/etc/ld.so.conf文件中配置.如果只想覆盖共享库的某几个函数, 保持其余函数不变, 则可以将共享库名字和函数名字输入到/etc/ld.so.preload中, 这里面定义的规则会覆盖标准规则.cache arrangement & ldconfig实际上, 在启动程序时再去搜寻所需的共享库不是高效做法, 所以loader使用了cache. ldconfig的作用就是读取文件/etc/ld.so.conf, 在各个库目录中, 对共享库设置合适的symbolic link(使得遵守命名约定), 然后写入某种数据到/etc/ld.so.cache, 这个文件再今后就被其他程序使用, 从而大幅提升了共享库的查找速度.所以在每加入/移除一个共享库, 或者修改了/etc/ld.so.conf(即修改库目录)的时候, 最要运行ldconfig.创建共享库step1. 编译出object files, 需要使用-fPIC或-fpic flag. fPIC和fpic的区别是, 前者生成的文件更大, 不过具有更好的平台无关性, 后者恰好相反. 这说明前者为了platform-independence做了更多工作.step2. 用-Wl向linker传递参数. 如: "gcc -shared-Wl,-soname,libmystuff.so.1 -o libmystuff.so.1.0.1 a.o b.o -lc".step3. 把共享库拷贝到约定的某个目录下即可, 如/usr/local/lib.step4. ldconfig -n /path/to/lib.elfelf的内容参考"elf & libelf, elftoolchain", 它是一种格式，也是一种规范, 可以用libelf写程序去操作它, 可以用objdump、nm和readelf去读取elf文件的内容.symbols我也已经熟悉共享库了, 我知道ldconfig的作用, 我知道常用的库放置目录, 我知道ltrace, ldd可以用来帮助确认某程序和某些共享库的关联关系是否正确.所以, 如果没有symbols这一节, 本篇文章存在的意义不大. "Inside ELF Symbol Tables"是绝佳的资料, 当然正如很多网文一样, 它仅是帮助理解, 而不涉及很深的细节. 细节标准什么的还是要看书和文档了, 这方面很不错的书籍就是校友的<程序员的自我修养>了.查看elf规范, 你必然可以看到symtab和dynsym, 如"ELF-64 Object File Format"中"4.Sections"就列出了标准的sections, .symtab和.dynsym就是其中之二.实际上, 我们知道机器可执行的是machine code, 而我们使用的高级语言编程, 并不是利用晦涩的机器码, 而是用human-readable的变量名, 函数名等, 这些名字就是symbolic name. 编译器在编译时收集symbol信息, 并储存在object file的.symtab和.dynsym中. symbols是linker和debugger所必需的信息, 如果没有symbols, 试想debugger如何能展示给用户调试信息了? 如果没有symbol, 而只有地址(相对于object file的offset), linker如何能够链接多个object file了?对于linker和symbol, 我们可以做个小实验: // 编写一个简单的a.c$ cat a.cvoid func(void){printf("call func()\n");}$ nm a.o00000000 T funcU puts// 编写一个简单的main.c$ cat main.c#include <stdio.h>extern void func(void);int main({func();return 0;}$ nm main.oU func00000000 T main// 正常情况下$ gcc main.o a.o -o main$ ./maincall func()// 为了验证symbol对于linker来说是必需品, 我做如下操作$ file a.oa.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped$ strip a.o$ file a.oa.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), stripped$ gcc main.o a.o -o mainmain.o: In function `main':/home/xan/lab/main.c:7: undefined reference to `func'collect2: ld returned 1 exit status这个小实验证实了symbols对于linker的重要性, 同时使用file看出"not stripped"->"stripped"的变化, 说的就是去除了symbols信息.现在假使我们生成了最后的可执行文件(当然是elf格式了), 那么这个elf中是否包含symbols呢? 其中又是否需要symbols呢?不妨先下结论: 一般地, 生成的可执行文件都是包含symbols, 不过这些信息不是程序执行所必需的, 可以通过strip(Discard symbols from object files)去除.同样可以做个小实验:// 仍用上面实验的代码$ file mainmain: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped$ ./maincall func()$ strip main$ file mainmain: ELF 32-bit LSB executable, Intel 80386, version 1(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped$ ./maincall func()$这个小实验证实了symbols对于可执行文件来说不是必需的, 这是因为可执行的代码都是machine code, 只需要address信息, 无需symbol信息.对于elf和symbols, 还是好理解的啦. 就是我elf文件中留了一席之地给你放symbols, compiler在生成elf时会往其中填充. debugger/nm/readelf等可以来读取. 不过这些symbols不是程序执行必需的, 所以完全可以去除, 只不过去除之后, debugger就读不到信息了.而对于共享库来说, 情况略复杂些了. 我们来特别说明.共享库和symbols在继续下去之前, 先来看两个事实.$ ldd /bin/lslinux-gate.so.1 => (0xb7711000)libselinux.so.1 => /lib/libselinux.so.1(0xb76e5000)librt.so.1 => /lib/i686/cmov/librt.so.1(0xb76dc000)libacl.so.1 => /lib/libacl.so.1 (0xb76d4000)libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb758d000)libdl.so.2 => /lib/i686/cmov/libdl.so.2(0xb7589000)/lib/ld-linux.so.2 (0xb7712000)libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7570000)libattr.so.1 => /lib/libattr.so.1 (0xb756b000)$ nm /lib/i686/cmov/libc.so.6nm: /lib/i686/cmov/libc.so.6: no symbols --> libattr, libacl也一样, 都显示"no symbols"// 而libpthread有一大串$ nm /lib/i686/cmov/libpthread.so.0 | tailU twalk@@GLIBC_2.0U uname@@GLIBC_2.0U unlink@@GLIBC_2.00000c930 t unwind_cleanup0000c970 t unwind_stop0000cfd0 W vfork0000de90 W wait0000df50 W waitpid0000c140 t walker0000d020 W write这仅仅是因为有些库做了strip, 而其他库没做strip而已? 还是说对于某些共享库来说, symbols也是必需的?目前不知答案, 分析下去.前面提到.symtab和.dynsym两个不同的symbol table, 它们有什么区别?.dynsym是.symtab的一个子集, 大家都有疑问, 为什么要两个信息重合的结构?需要先了解allocable/non-allocable ELF section, ELF文件包含一些sections(如code和data)是在运行时需要的, 这些sections被称为allocable; 而其他一些sections仅仅是linker,debugger等工具需要, 在运行时并不需要, 这些sections被称为non-allocable的. 当linker构建ELF文件时, 它把allocable的数据放到一个地方, 将non-allocable的数据放到其他地方. 当OS加载ELF文件时, 仅仅allocable的数据被映射到内存, non-allocable的数据仍静静地呆在文件里不被处理. strip就是用来移除某些non-allocable sections的..symtab包含大量linker,debugger需要的数据, 但并不为runtime必需, 它是non-allocable的; .dynsym包含.symtab的一个子集, 比如共享库所需要在runtime加载的函数对应的symbols, 它世allocable的.因此, 得到答案:1. strip移除的应是.symtab.2. nm读取的应是.symtab: 上面发现的libattr等nm结果为空, libpthread nm结果非空应是正常的.3. 共享库包含的.dynsym是runtime必需的, 是allocable的. 可做验证, 期望的结果为:1. strip libpthread, ls依然能够工作.2. strip libpthread, nm libpthread得到结果为空.3. 可以通过设置nm options, 或使用readelf读出.dynsym的内容.$ sudo strip /lib/i686/cmov/libpthread-2.11.3.so$ file /lib/i686/cmov/libpthread-2.11.3.so/lib/i686/cmov/libpthread-2.11.3.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped$ ls...(输出正确结果)$ nm /lib/i686/cmov/libpthread-2.11.3.sonm: /lib/i686/cmov/libpthread-2.11.3.so: no symbols$ readelf -s /lib/i686/cmov/libpthread-2.11.3.so | tail322: 0000b6a0 292 FUNC GLOBAL DEFAULT 13 __pthread_clock_gettime@@GLIBC_PRIV ATE323: 0000ec30 46 FUNC GLOBAL DEFAULT 13 pthread_mutex_consistent_@@GLIBC_2.4324: 0000b3a0 50 FUNC GLOBAL DEFAULT 13 pthread_testcancel@@GLIBC_2.0325: 0000d6b0 111 FUNC WEAK DEFAULT 13 fsync@@GLIBC_2.0326: 0000d1f0 180 FUNC WEAK DEFAULT 13 fcntl@@GLIBC_2.0327: 0000dde0 176 FUNC WEAK DEFAULT 13tcdrain@@GLIBC_2.0328: 00009390 7 FUNC GLOBAL DEFAULT 13 pthread_mutexattr_destroy@@GLIBC_2.0329: 00006de0 23 FUNC GLOBAL DEFAULT 13 pthread_yield@@GLIBC_2.2330: 000077c0 259 FUNC GLOBAL DEFAULT 13 pthread_mutex_init@@GLIBC_2.0331: 000093c0 49 FUNC GLOBAL DEFAULT 13 pthread_mutexattr_setpsha@@GLIBC_2.2$ readelf -s /lib/libattr.so.1.1.0 | tail48: 00002f50 50 FUNC GLOBAL DEFAULT 13 lremovexattr@@ATTR_1.049: 00003010 57 FUNC GLOBAL DEFAULT 13 llistxattr@@ATTR_1.050: 00002ae0 50 FUNC GLOBAL DEFAULT 13 attr_copy_check_permissio@@ATTR_1.151: 00001b50 259 FUNC GLOBAL DEFAULT 13 attr_set@@ATTR_1.052: 00002b20 1002 FUNC GLOBAL DEFAULT 13 attr_copy_action53: 000031f0 71 FUNC GLOBAL DEFAULT 13setxattr@@ATTR_1.054: 00001380 543 FUNC GLOBAL DEFAULT 13 attr_list@@ATTR_1.255: 000030d0 64 FUNC GLOBAL DEFAULT 13 lgetxattr@@ATTR_1.056: 00002fd0 57 FUNC GLOBAL DEFAULT 13 flistxattr@@ATTR_1.057: 00002f10 50 FUNC GLOBAL DEFAULT 13 fremovexattr@@ATTR_1.0至此, 对symbols和共享库,ELF的关系的了解告一段落. more既然已经说到共享库(shared library), 不妨稍微提一下动态装载库(Dynamically Loaded Libraries), 共享库是在程序startup 时被加载, 而DLL(注意区别于windows下的概念)则是在程序运行过程中显式被加载, 实际上就是调用dlopen,dlsym等接口显式地打开共享库, 显示地查找库中的symbol, 然后找到对应的代码去执行.How To Write Shared Libraries by Ulrich Drepper.--EOF--。
abap 'm' 的意思-概述说明以及解释1.引言1.1 概述"abap 'm' 的意思"这个标题引发了人们的好奇心和疑惑。
在ABAP 编程语言中使用的字符'M'在许多情况下有着重要的意义和用途。
首先，'M'是ABAP中的一个特殊符号，代表着"修改"。
在许多情况下，我们需要对数据或对象进行修改操作，而ABAP编程语言为我们提供了使用'M'来表示这样的操作。
这让我们能够清楚地识别出一个特定的行为是修改相关的。
其次，'M'也可以表示"模型"。
在ABAP中，模型是对数据结构和逻辑的抽象和建模。
使用'M'作为模型的标识符，我们可以更容易地识别和理解代码中的模型部分。
这种命名约定使得代码更易读、易于维护和理解。
另外，'M'还代表着"多态"。
在ABAP中，多态是一种面向对象编程的概念，它允许我们使用一种通用的方式处理不同类型的数据。
通过使用'M'作为多态标识符，我们可以更好地实现代码的灵活性和可重用性。
综上所述，'M'在ABAP编程语言中有着多重意义和用途。
它代表着修改、模型和多态。
这种命名约定使得代码更加清晰、易读和易于维护。
这也展示了ABAP作为一种强大而灵活的编程语言的优势。
1.2 文章结构本文主要由引言、正文和结论三个部分构成。
在引言部分，我们将对整篇文章进行一个简要的概述，介绍ABAP 'M'的意思以及本文的目的。
接着，我们将详细介绍文章的结构安排，让读者能够清晰地了解本文的篇章结构。
接下来是正文部分，本文将围绕着ABAP 'M'展开讨论。
在第一个要点中，我们将介绍ABAP的概念和背景，并详细讨论ABAP 'M'的含义以及其在ABAP开发中的作用和重要性。
竭诚为您提供优质文档/双击可除pascal命名规范篇一：pascal命名规范约定暨驼蜂式命名pascal命名规范约定暨驼蜂式命名许多命名约定都与标识符的大小写有关。
值得注意的是，公共语言运行库(clR)支持区分大小写和不区分大小写的语言。
本主题中描述的大小写约定可帮助开发人员理解和使用库。
大小写样式下列术语描述了标识符的不同大小写形式。
pascal大小写将标识符的首字母和后面连接的每个单词的首字母都大写。
可以对三字符或更多字符的标识符使用pascal大小写。
例如：backcolor大小写混合标识符的首字母小写，而每个后面连接的单词的首字母都大写。
例如：backcolor大写标识符中的所有字母都大写。
例如：io标识符的大小写规则如果标识符由多个单词组成，请不要在各单词之间使用分隔符，如下划线（“_”）或连字符（“-”）等。
而应使用大小写来指示每个单词的开头。
下列准则是用于标识符的通用规则。
对于由多个单词组成的所有公共成员、类型及命名空间名称，要使用pascal大小写。
注意，这条规则不适用于实例字段。
由于成员设计准则中详细说明的原因，不应使用公共实例字段。
对参数名称使用大小写混合。
下表汇总了标识符的大小写规则，并提供了不同类型标识符的示例。
标识符大小写方式示例类枚举类型枚举值事件异常类接口方法命名空间参数pascalpascalpascalpascalpascalpascalpascalpascalcam elappdomainerrorlevelFatalerrorValuechangedwebexcep tionRedValueidisposabletostringsystem.drawingtypena me只读的静态字段pascal属性pascalbackcolor首字母缩写词的大小写规则首字母缩写词是由术语或短语中各单词的首字母构成的单词。
例如，html是hypertextmarkuplanguage的首字母缩写。
请简述标识符的命名规则标识符命名规则在编程中是非常重要的，它是指在程序中使用的变量名、函数名、常量名等所必须满足的规则。
只有遵守这些规则，才能保证程序的正确性和可读性，从而使程序更加易于维护和扩展。
标识符命名规则包括标识符命名的要求、命名的约定和命名的规范等多个方面，下面将对它们进行详细的介绍。
一、标识符命名的要求标识符命名的基本要求是要有意义、简明清晰，易于理解和使用，同时还要具有可读性和可维护性。
具体来说，它应该遵循以下几个原则：1、简单易懂：标识符的名称要简单明了，尽量使用直观并与其意义相关联的名称。
2、有意义：标识符的名称应能够表达其所代表的事物的含义，能够清晰表达其功能。
3、符合语法：标识符的命名应该遵循所用编程语言的语法，命名不能包含特殊符号、空格等非法标识符。
4、唯一性：每个标识符在程序中都应该唯一，不能有同名的标识符，否则会导致编译错误。
5、长度合理：标识符不宜过长或过短，建议长度在2到20个字符之间，要符合实际情况。
二、命名的约定在编程中，不同的编程语言对标识符的命名规则有不同的约定，但也有些公认的命名约定，例如：1、驼峰命名法（Camel Case）：多用于Java、C++等面向对象编程语言。
由若干单词组成，除第一个单词外其余单词首字母大写，单词间不空格：例子：firstName、lastName、productPrice 。
2、帕斯卡命名法（Pascal Case）：多用于C#、Delphi等面向对象编程语言。
由若干单词组成，每个单词首字母大写，单词间不空格：例子：FirstName、LastName、ProductPrice。
3、下划线命名法（Snake Case）：多用于Python、Ruby等脚本语言。
由若干单词组成，单词间以下划线分隔：例子：first_name、last_name、product_price。
三、命名的规范除了一些基本的要求和约定之外，标识符的命名还应该符合以下规范：1、避免使用单个字符的名称：如，i、j、x、y等。
第五章 数据集的处理5.1 数据集定义z/OS 数据集是存储在一个磁盘卷或者多个磁盘卷上，逻辑相关的数据记录的集合。
例如, 一个数据集可以是一个源程序、一个宏库或一个能够被应用程序使用的数据记录文件。
用户可以在终端上打印或显示数据集。
逻辑记录是应用程序使用的基本信息单元。
数据可以存储在直接访问存储设备上（DASD） ，磁带卷或者光媒体上。
正如前面提到的， DASD适用于磁盘或与磁盘类似的设备。
所有类型的数据集都可以存储在DASD上，但是只有顺序数据集能够存储在磁带上。
我们将在后面讨论数据集的类型。
5.2 数据集命名每当用户分配一个新的数据集时,必须给数据集一个唯一的名字。
一个数据集名可能是一个名字段, 或一系列联合的名字段。
每个名字段描述了一个限定标准，例如,数据集名TECH01.COBOL.DATA是由三个名字段组成。
左边的第一个名字段被称为高级限定词(HLQ-high-level qualifier)，右边的最后一个名字段是最低级的限定词(LLQ- lowest-level qualifier)。
每个名字段的长度可以是一到八个字符，名字段的第一个字母必须是字母(A到Z)或national符号(#，@，$)，剩下的七个字符是任一字母、数字(0-9)、national符号或一个连接符号(-)。
名字段之间用句点(.)相隔。
包括所有的名字段和句点,数据集名的长度不能超过44个字符。
因此，一个数据集名最多可以由22个名字段组成。
5.2.1 HLQ命名约定一个数据集的HLQ是由安全系统控制的，其余的名字段也有许多命名约定，这些是约定而不是标准,但是它们被广泛地使用，它们包括下列各项：（1）名字中的字符LIB表示数据集是一个库，字符PDS也可以表示一个库，但它较少使用。
（2）名字中的字符CNTL、JCL或JOB表示数据集中包含JCL( 但是不一定专用于JCL)。
（3） 名字中的字符LOAD、LOADLIB或LINKLIB表示数据集中包含可运行的模块（一个具有z/OS可执行模块的库必须是单独的可执行模块)。
