One of the reasons for continuing to use capitalization is when you(or someone else) are viewing code in something like notepad, it makes it easier to read. i.e. you can differentiate easily between the "keywords" and the tablenames, SP's, udf's etc
尝试格式化产品（我使用 Red Gate 的 SQL Prompt/SQL Refactor）。 您可以设置大小写的工作方式，并且您的代码将始终保持一致的格式。 休息一下你的小指，让计算机为你完成工作。
Try a formatting product (I use SQL Prompt/SQL Refactor from Red Gate). You can set how you want the capitalization to work, and your code will always be consistently formatted. Rest your pinky and let the computer do the work for you.
我从 PHP 中调用大部分 mySQL 代码，并在 vim 中完成所有 PHP 编辑（或者我想在本例中是 VIM ；-）。 现在我确信有插件可以突出显示 PHP 中的 mySQL 代码，但我还没有找到它，而且我也没有时间去寻找它。 因此，我更喜欢将所有内容全部大写。 我发现这个：
if ( !$bla )
{
echo "select something from something where something";
}
if ( !$beepboop )
{
echo "create table if not exists loremIpsum;
}
$query = "
CREATE TABLE IF NOT EXISTS HISTORY
(
ID INT NOT NULL AUTO_INCREMENT,
INSERTDATE TIMESTAMP DEFAULT NOW(),
ALTERDATE TIMESTAMP(8) DEFAULT NOW(),
DELETEDATE TIMESTAMP(8),
ALTERCOUNT INT DEFAULT 0,
SELECTCOUNT INT DEFAULT 0,
PRIMARY KEY(ID),
)ENGINE=InnoDB
";
mysqlQuery( $query, $con );
帮助我区分 PHP 与 SQL 比这个好得多：
if ( !$bla )
{
echo "select something from something where something";
}
if ( !$beepboop )
{
echo "create table if not exists loremIpsum;
}
$query = "
create table if not exists history
(
id int not null auto_increment,
insertdate timestamp default now(),
alterdate timestamp(8) default now(),
deletedate timestamp(8),
altercount int default 0,
selectcount int default 0,
primary key(id),
)engine=InnoDB
";
mysqlQuery( $query, $con );
另外，出于某种原因，我讨厌将大写字母与驼峰式大小写混合，就像这样：
CREATE TABLE IF NOT EXISTS history
(
ID INT NOT NULL AUTO_INCREMENT,
insertDate TIMESTAMP DEFAULT NOW(),
alterDate TIMESTAMP(8) DEFAULT NOW(),
deleteDate TIMESTAMP(8),
alterCount INT DEFAULT 0,
selectCount INT DEFAULT 0,
PRIMARY KEY(ID),
)ENGINE=InnoDB
那个 ID 让我很恼火。 它应该是 id 吗？ 或iD？
I call most of my mySQL code from within PHP, and I do all of my PHP editing within vim (or I suppose in this case, VIM ;-). Now I am sure there are plugins out there to highlight the mySQL code within PHP, but I have not found it, and I don't have to the time to go looking for it. Therefore, I prefer to have everything in allcaps. I find this:
if ( !$bla )
{
echo "select something from something where something";
}
if ( !$beepboop )
{
echo "create table if not exists loremIpsum;
}
$query = "
CREATE TABLE IF NOT EXISTS HISTORY
(
ID INT NOT NULL AUTO_INCREMENT,
INSERTDATE TIMESTAMP DEFAULT NOW(),
ALTERDATE TIMESTAMP(8) DEFAULT NOW(),
DELETEDATE TIMESTAMP(8),
ALTERCOUNT INT DEFAULT 0,
SELECTCOUNT INT DEFAULT 0,
PRIMARY KEY(ID),
)ENGINE=InnoDB
";
mysqlQuery( $query, $con );
Helps me distinguish between PHP versus SQL a lot better than this:
if ( !$bla )
{
echo "select something from something where something";
}
if ( !$beepboop )
{
echo "create table if not exists loremIpsum;
}
$query = "
create table if not exists history
(
id int not null auto_increment,
insertdate timestamp default now(),
alterdate timestamp(8) default now(),
deletedate timestamp(8),
altercount int default 0,
selectcount int default 0,
primary key(id),
)engine=InnoDB
";
mysqlQuery( $query, $con );
Also, for some reason, I hate mixing allcaps with camel case, like so:
CREATE TABLE IF NOT EXISTS history
(
ID INT NOT NULL AUTO_INCREMENT,
insertDate TIMESTAMP DEFAULT NOW(),
alterDate TIMESTAMP(8) DEFAULT NOW(),
deleteDate TIMESTAMP(8),
alterCount INT DEFAULT 0,
selectCount INT DEFAULT 0,
PRIMARY KEY(ID),
)ENGINE=InnoDB
I dislike anything written in all caps (and hate typing all caps even more), but couldn't convince myself to go against the community. As usual Vim and its associated packages are the solution to so many problems:
除了为了顺从而顺从之外，没有。 尽管这是一个非常主观的主题，但我更喜欢对所有 SQL 使用混合大小写。 SQL 更容易阅读，并且在现代 IDE 中不会丢失任何内容，无论如何关键字都是用颜色编码的。
Other than conformity for conformitys sake, no. Although it's a very subjective topic, I prefer using mixed case for all SQL. The SQL is much easier to read, and nothing is lost in modern IDEs where keywords are all color-coded anyway.
Microsoft SQL Server Management Studio 中的智能感知/自动完成功能允许保留字使用大写或小写，但允许大写的函数调用，例如 MAX()、SUM()。
即便如此，解析器仍然允许处理小写版本的 max() 和 sum()。
这意味着对执行性质的矛盾心理，因此只是个人喜好问题。
The intellisense/autocompletion in Microsoft SQL Server Management Studio allows either upper or lower case for reserved words, but upper cases function calls like MAX(), SUM().
Even so, the parser still allows lower case versions of max() and sum() to be processed.
This implies an ambivalence with regard to the nature of execution, and therefore is simply a matter of personal preference.
SQL IS OLD. UPPER CASE IS SHOUTING. IT LOOKS STRANGE AND PERHAPS UGLY.
While arguably true, none of those address the reasons special to the SQL language why upper-case keywords are a good convention.
Unlike many newer languages, SQL has a large number of keywords and relies on the reader's ability to distinguish keywords versus identifiers in order to mentally parse the syntax.
The direct answer to your question, then, is more an answer to “why does the reader of SQL code benefit so much from uppercase keywords, when that's not as true for most modern languages?”:
To rely on keeping the keywords in one's head is reasonable for many modern languages, but unreasonable for SQL; it has too many keywords, and too many variants.
To rely on punctuation cues is reasonable for most modern languages, but unreasonable for SQL; it has too few, instead depending on the precise order of keywords to indicate syntax.
To rely on automatic highlighters for distinguishing keywords is reasonable for modern languages in usual cases, but ignores the reality of what highlighters can achieve for SQL. Most don't cover all keywords of all variants of SQL, and regardless, SQL is frequently and routinely read in contexts where a highlighter won't help.
These are some of the reasons, specific to SQL, that the reader of SQL code is best served by standardising on upper case for keywords, and only using not-upper (i.e. lower, or mixed) case for identifiers.
Highlighting can sometimes help. But only if the highlighter knows you've got SQL; and we very often have SQL in a context where the editor/formatter can't reasonably know it's dealing with SQL. Examples include in-line queries, programmer documentation, and text strings within the code of another language. The same is not true anywhere near as often for languages like Python or C++; yes, their code does sometimes appear in those places, but it's not routinely done the way it is with SQL code.
Also, the reader will commonly be using a highlighter that only knows a subset of the keywords your specific SQL implementation uses. Many of the less-common keywords won't be highlighted except by one that knows your SQL variant intimately. So the reader, even if they're using a highlighter, still needs some more direct way of distinguishing keywords in any moderately-complex SQL statement.
Thus the reader will frequently – and the writer can't know ahead of time when that will be – need assistance from the content of the SQL statement itself, to know what's intended by the writer as a keyword and what's intended as an identifier. So the SQL content itself needs to distinguish keywords for the reader, and using uppercase keywords is the conventional and useful way to do that.
THERE WAS A TIME WHEN MOST PEOPLE DID NOT HAVE THE POSSIBILITY OF ENCODING ANYTHING BEYOND UPPER CASE LETTERS BECAUSE THE RELEVANT ENCODING (ASCII) WAS NOT YET INVENTED. ONLY SIX BITS WERE AVAILABLE. WHILE SQL IS MORE RECENT, LOWER CASE LETTERS WERE NOT COMMON PRACTICE IN PROGRAMMING YET.
NOTE THAT SOME PEOPLE CLAIM THAT THE DATABASE WILL GET A SENSE OF URGENCY AND RUN YOUR QUERIES FASTER.
SELECT name, id, xtype, uid, info, status,
base_schema_ver, replinfo, parent_obj, crdate,
ftcatid, schema_ver, stats_schema_ver, type,
userstat, sysstat, indexdel, refdate, version,
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1
我发现这更容易阅读，因为关键字更突出。 即使使用语法突出显示，我发现未大写的示例更难以阅读。
在我的公司，我们在 SQL 格式化方面走得更远。
SELECT name, id, xtype, uid, info, status,
base_schema_ver, replinfo, parent_obj, crdate,
ftcatid, schema_ver, stats_schema_ver, type,
userstat, sysstat, indexdel, refdate, version,
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
sysobjects.col1=systhingies.col2
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1
Gordon Bell's examples are not exactly correct; generally, only the keywords are highlighted, not the entire query. His second example would look like:
SELECT name, id, xtype, uid, info, status,
base_schema_ver, replinfo, parent_obj, crdate,
ftcatid, schema_ver, stats_schema_ver, type,
userstat, sysstat, indexdel, refdate, version,
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1
I find this far easier to read, since the keywords stand out more. Even with syntax highlighting, I find the uncapitalized example much harder to read.
At my company, we go a little bit farther with our SQL formatting.
SELECT name, id, xtype, uid, info, status,
base_schema_ver, replinfo, parent_obj, crdate,
ftcatid, schema_ver, stats_schema_ver, type,
userstat, sysstat, indexdel, refdate, version,
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
sysobjects.col1=systhingies.col2
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1
Less than 10% of the letters in the text we read are upper case. Hence our brains are more keen at recognizing lower case letters than upper case ones. Studies have shown it takes longer to read upper case text. Here is just one example:
It's because SQL is such an old language (1974) that when it was conceived, most keyboards didn't have lowercase letters! The language documentation simply reflected the technology of the time.
The lettering for names of places, streets, and highways on conventional road guide signs shall be a combination of lowercase letters with initial uppercase letters.
The New York Post also published:
Studies have shown that it is harder to read all-caps signs, and those extra milliseconds spent staring away from the road have been shown to increase the likelihood of accidents, particularly among older drivers.
There is no good reason to use uppercase letters, and good reasons not to.
I personally loath using uppercase for SQL keywords. I find it harder to read and absurd in this day and age.
The SQL language is defined as being case-insensitive. Take your finger off that shift key!
Upper case can provide a gain in keyword visibility, but you can compensate with code highlight and indentation. We use lower case because query editor and other tools do wonders in editing t-sql code, and we see no need to torture the little finger.
发布评论
评论（17）
继续使用大写的原因之一是当您（或其他人）在记事本之类的工具中查看代码时，它更容易阅读。 即您可以轻松区分“关键字”和表名、SP、udf 等
One of the reasons for continuing to use capitalization is when you(or someone else) are viewing code in something like notepad, it makes it easier to read. i.e. you can differentiate easily between the "keywords" and the tablenames, SP's, udf's etc
尝试格式化产品（我使用 Red Gate 的 SQL Prompt/SQL Refactor）。 您可以设置大小写的工作方式，并且您的代码将始终保持一致的格式。 休息一下你的小指，让计算机为你完成工作。
Try a formatting product (I use SQL Prompt/SQL Refactor from Red Gate). You can set how you want the capitalization to work, and your code will always be consistently formatted. Rest your pinky and let the computer do the work for you.
我从 PHP 中调用大部分 mySQL 代码，并在 vim 中完成所有 PHP 编辑（或者我想在本例中是 VIM ；-）。 现在我确信有插件可以突出显示 PHP 中的 mySQL 代码，但我还没有找到它，而且我也没有时间去寻找它。 因此，我更喜欢将所有内容全部大写。 我发现这个：
帮助我区分 PHP 与 SQL 比这个好得多：
另外，出于某种原因，我讨厌将大写字母与驼峰式大小写混合，就像这样：
那个
ID让我很恼火。 它应该是id吗？ 或iD？I call most of my mySQL code from within PHP, and I do all of my PHP editing within vim (or I suppose in this case, VIM ;-). Now I am sure there are plugins out there to highlight the mySQL code within PHP, but I have not found it, and I don't have to the time to go looking for it. Therefore, I prefer to have everything in allcaps. I find this:
Helps me distinguish between PHP versus SQL a lot better than this:
Also, for some reason, I hate mixing allcaps with camel case, like so:
That
IDirks me. Should it instead beid? oriD?我不喜欢所有大写的内容（并且更讨厌全部大写），但无法说服自己违背社区。 像往常一样，Vim 及其相关软件包可以解决许多问题：
http:// www.vim.org/scripts/script.php?script_id=305
只需照常输入，它就会在您输入时自动将关键字大写。 我没有使用过所有晦涩难懂的 SQL 咒语，但它还没有让我失望。
I dislike anything written in all caps (and hate typing all caps even more), but couldn't convince myself to go against the community. As usual Vim and its associated packages are the solution to so many problems:
http://www.vim.org/scripts/script.php?script_id=305
Simply type as normal and it will auto-capitalize the keywords as you type. I haven't used all obscure SQL incantations but it hasn't failed me yet.
除了为了顺从而顺从之外，没有。 尽管这是一个非常主观的主题，但我更喜欢对所有 SQL 使用混合大小写。 SQL 更容易阅读，并且在现代 IDE 中不会丢失任何内容，无论如何关键字都是用颜色编码的。
Other than conformity for conformitys sake, no. Although it's a very subjective topic, I prefer using mixed case for all SQL. The SQL is much easier to read, and nothing is lost in modern IDEs where keywords are all color-coded anyway.
Microsoft SQL Server Management Studio 中的智能感知/自动完成功能允许保留字使用大写或小写，但允许大写的函数调用，例如 MAX()、SUM()。
即便如此，解析器仍然允许处理小写版本的 max() 和 sum()。
这意味着对执行性质的矛盾心理，因此只是个人喜好问题。
The intellisense/autocompletion in Microsoft SQL Server Management Studio allows either upper or lower case for reserved words, but upper cases function calls like MAX(), SUM().
Even so, the parser still allows lower case versions of max() and sum() to be processed.
This implies an ambivalence with regard to the nature of execution, and therefore is simply a matter of personal preference.
这只是一个风格问题，可能起源于编辑器不进行代码着色的时代。
我以前更喜欢全部大写，但现在倾向于全部小写。
无论哪种方式，都要保持一致。
It's just a matter of style, probably originating in the days when editors didn't do code colouring.
I used to prefer all upper case, but I'm now leaning towards all lower.
Either way, be consistent.
SQL 很旧。 大写字母在喊叫。 它看起来很奇怪，也许还很丑。
虽然可以说是正确的，但这些都没有解决 SQL 语言特有的原因，即为什么大写关键字是一个很好的约定。
与许多较新的语言不同，SQL 拥有大量关键字，并且依赖于读者区分关键字与标识符的能力，以便在心里解析语法。
那么，对你的问题的直接回答更多的是回答“为什么 SQL 代码的读者能从大写关键字中受益匪浅，而对于大多数现代语言来说情况并非如此？”：
依靠牢记关键字对于许多现代语言来说是合理的，但对于 SQL 来说是不合理的； 它有太多的关键字，也有太多的变体。
依赖标点符号提示对于大多数现代语言来说是合理的，但对于 SQL 来说是不合理的； 它的数量太少，而是依靠关键字的精确顺序来指示语法。
在通常情况下，依靠自动突出显示来区分关键字对于现代语言来说是合理的，但忽略了突出显示对于 SQL 可以实现的现实。 大多数都没有涵盖 SQL 的所有变体的所有关键字，而且无论如何，SQL 经常在荧光笔无济于事的上下文中阅读。
这些是特定于 SQL 的一些原因，SQL 代码的读者最好通过对关键字的大写进行标准化，并且仅使用非大写（即小写或混合）大小写来为 SQL 代码的读者提供最好的服务。身份标识。
突出显示有时会有所帮助。 但前提是荧光笔知道你有 SQL； 我们经常在编辑器/格式化程序无法合理地知道它正在处理 SQL 的上下文中使用 SQL。 示例包括内联查询、程序员文档和另一种语言代码中的文本字符串。 对于 Python 或 C++ 等语言来说，情况并非如此。 是的，他们的代码有时确实会出现在这些地方，但通常不会像 SQL 代码那样完成。
此外，读者通常会使用只知道特定 SQL 实现使用的关键字子集的荧光笔。 许多不太常见的关键字不会突出显示，除非非常了解您的 SQL 变体的关键字。 因此，即使读者使用荧光笔，他们仍然需要一些更直接的方法来区分任何中等复杂的 SQL 语句中的关键字。
因此，读者经常需要 SQL 语句本身内容的帮助（而编写者无法提前知道何时会发生），以了解编写者想要将什么作为关键字以及什么作为标识符。 因此，SQL 内容本身需要为读者区分关键字，而使用大写关键字是实现这一点的传统且有用的方法。
SQL IS OLD. UPPER CASE IS SHOUTING. IT LOOKS STRANGE AND PERHAPS UGLY.
While arguably true, none of those address the reasons special to the SQL language why upper-case keywords are a good convention.
Unlike many newer languages, SQL has a large number of keywords and relies on the reader's ability to distinguish keywords versus identifiers in order to mentally parse the syntax.
The direct answer to your question, then, is more an answer to “why does the reader of SQL code benefit so much from uppercase keywords, when that's not as true for most modern languages?”:
To rely on keeping the keywords in one's head is reasonable for many modern languages, but unreasonable for SQL; it has too many keywords, and too many variants.
To rely on punctuation cues is reasonable for most modern languages, but unreasonable for SQL; it has too few, instead depending on the precise order of keywords to indicate syntax.
To rely on automatic highlighters for distinguishing keywords is reasonable for modern languages in usual cases, but ignores the reality of what highlighters can achieve for SQL. Most don't cover all keywords of all variants of SQL, and regardless, SQL is frequently and routinely read in contexts where a highlighter won't help.
These are some of the reasons, specific to SQL, that the reader of SQL code is best served by standardising on upper case for keywords, and only using not-upper (i.e. lower, or mixed) case for identifiers.
Highlighting can sometimes help. But only if the highlighter knows you've got SQL; and we very often have SQL in a context where the editor/formatter can't reasonably know it's dealing with SQL. Examples include in-line queries, programmer documentation, and text strings within the code of another language. The same is not true anywhere near as often for languages like Python or C++; yes, their code does sometimes appear in those places, but it's not routinely done the way it is with SQL code.
Also, the reader will commonly be using a highlighter that only knows a subset of the keywords your specific SQL implementation uses. Many of the less-common keywords won't be highlighted except by one that knows your SQL variant intimately. So the reader, even if they're using a highlighter, still needs some more direct way of distinguishing keywords in any moderately-complex SQL statement.
Thus the reader will frequently – and the writer can't know ahead of time when that will be – need assistance from the content of the SQL statement itself, to know what's intended by the writer as a keyword and what's intended as an identifier. So the SQL content itself needs to distinguish keywords for the reader, and using uppercase keywords is the conventional and useful way to do that.
就我个人而言，我不喜欢 SQL 对我大喊大叫。 它让我想起 BASIC 或 COBOL。
因此，我更喜欢使用小写字母的 T-SQL 和混合大小写的数据库对象名称。
它更容易阅读，文字和注释也很突出。
PERSONALLY, I DON'T LIKE MY SQL YELLING AT ME. IT REMINDS ME OF BASIC OR COBOL.
So I prefer my T-SQL lowercase with database object names MixedCase.
It is much easier to read, and literals and comments stand out.
曾经有一段时间，大多数人无法对大写字母以外的任何内容进行编码，因为相关的编码 (ASCII) 尚未发明。 只有六位可用。 虽然 SQL 是最近才出现的，但小写字母在编程中还不是常见的做法。
请注意，有些人声称数据库会产生紧迫感并更快地运行您的查询。
THERE WAS A TIME WHEN MOST PEOPLE DID NOT HAVE THE POSSIBILITY OF ENCODING ANYTHING BEYOND UPPER CASE LETTERS BECAUSE THE RELEVANT ENCODING (ASCII) WAS NOT YET INVENTED. ONLY SIX BITS WERE AVAILABLE. WHILE SQL IS MORE RECENT, LOWER CASE LETTERS WERE NOT COMMON PRACTICE IN PROGRAMMING YET.
NOTE THAT SOME PEOPLE CLAIM THAT THE DATABASE WILL GET A SENSE OF URGENCY AND RUN YOUR QUERIES FASTER.
戈登·贝尔的例子并不完全正确； 通常，仅突出显示关键字，而不突出显示整个查询。 他的第二个例子如下：
我发现这更容易阅读，因为关键字更突出。 即使使用语法突出显示，我发现未大写的示例更难以阅读。
在我的公司，我们在 SQL 格式化方面走得更远。
Gordon Bell's examples are not exactly correct; generally, only the keywords are highlighted, not the entire query. His second example would look like:
I find this far easier to read, since the keywords stand out more. Even with syntax highlighting, I find the uncapitalized example much harder to read.
At my company, we go a little bit farther with our SQL formatting.
我们阅读的文本中只有不到 10% 的字母是大写的。 因此，我们的大脑比大写字母更热衷于识别小写字母。 研究表明，阅读大写文本需要更长的时间。 这里只是一个例子：
http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals
我认为上面的例子强调了即使当你只谈论一两个词时，就会产生影响。
Less than 10% of the letters in the text we read are upper case. Hence our brains are more keen at recognizing lower case letters than upper case ones. Studies have shown it takes longer to read upper case text. Here is just one example:
http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals
The above example I think emphasizes that even when you're talking about just one or two words, it makes a difference.
这是因为 SQL 是一种非常古老的语言（1974），因此在构思它时，大多数键盘都没有没有小写字母！ 语言文档只是反映了当时的技术。
科学研究证明全部大写字母更难阅读，以至于美国联邦公路管理局已强制使用统一交通控制设备手册中的混合大小写标志指出：
《纽约邮报》还发表了：
没有充分的理由使用大写字母，也没有充分的理由不使用。
我个人不喜欢使用大写的 SQL 关键字。 我发现在当今时代，这本书很难读，而且很荒谬。
SQL 语言被定义为不区分大小写。 把你的手指从 Shift 键上拿开！
It's because SQL is such an old language (1974) that when it was conceived, most keyboards didn't have lowercase letters! The language documentation simply reflected the technology of the time.
Scientific research has proven ALL CAPS is harder to read, so much so that the USA Federal Highway Administration has mandated the use of mixed-case signs in their Manual on Uniform Traffic Control Devices, which states:
The New York Post also published:
There is no good reason to use uppercase letters, and good reasons not to.
I personally loath using uppercase for SQL keywords. I find it harder to read and absurd in this day and age.
The SQL language is defined as being case-insensitive. Take your finger off that shift key!
大写字母可以提高关键字可见性，但您可以通过代码突出显示和缩进进行补偿。
我们使用小写字母是因为查询编辑器和其他工具在编辑 t-sql 代码方面可以创造奇迹，而且我们认为没有必要折磨小指。
Upper case can provide a gain in keyword visibility, but you can compensate with code highlight and indentation.
We use lower case because query editor and other tools do wonders in editing t-sql code, and we see no need to torture the little finger.
我发现它更具可读性。 每个子句的开头有一个换行符以及子句之间的缩进也是如此。
I find it more readable. Same for having a newline for the beginning of each clause and indenting between clauses.
猴子看，猴子为我做。 模式匹配 - 如果我按照我所看到的方式进行操作，则子句的结构在心理上会更容易排列。
Monkey see, monkey do for me. Pattern matching - if I do it the way I've seen it done, the structure of the clauses lines up mentally more easily.
大写字母的可读性较差。 所有文字的轮廓都是盒子的形状； 没有下降或上升。 小写 FTW！
Uppercase is less readable. The outline of all words are shaped like boxes; there are no descenders or ascenders. Lowercase FTW!