什么是你被迫遵循的最奇怪的编码标准规则？
当我问这个问题时，我几乎总是肯定的，你应该有编码标准。
什么是你曾经被迫遵循的最奇怪的编码标准规则？
而最奇怪的是，我的意思是最有趣的，或者最糟糕的，或者仅仅是奇怪的。
在每个答案中，请提及哪种语言，您的团队规模，以及您和您的团队造成的不良影响。
我讨厌使用多重回报被禁止。
反向缩进。 例如：
for(int i = 0; i < 10; i++) { myFunc(); } 和：
if(something) { // do A } else { // do B }
也许不是最古怪的一个，但我真的很讨厌，当我必须在数据库表名前添加'tbl'
几乎所有的匈牙利符号。
匈牙利语的问题在于它经常被人误解。 最初的想法是在variables的前面加上意思是清楚的。 例如：
int appCount = 0; // Number of apples. int pearCount = 0; // Number of pears.
但大多数人用它来确定types。
int iAppleCount = 0; // Number of apples. int iPearCount = 0; // Number of pears.
这是令人困惑的，因为尽pipe这两个数字都是整数，但大家都知道，苹果和梨不能相提并论。
没有三元操作员允许我目前工作的地方：
int value = (a < b) ? a : b;
…因为不是每个人都“得到它”。 如果你告诉我：“不要使用它，因为当结构变得太复杂的时候我们不得不重写它们（嵌套的三元运算符，任何人？），那我就明白了。 但是当你告诉我一些开发者不了解他们的时候…呃…当然。
永远不要删除任何代码进行更改。 我们被告知要评论所有的变化。 请记住，我们使用源代码pipe理。 这个政策并没有持续太久，因为开发者们对此感到</s>怒，以及如何让代码变得不可读。
我曾经在强大的VB国王的专制下工作过。
VB国王是MS Excel和VBA以及数据库的纯粹大师（ 因此，他的姓：他与Excel一起玩，而开发人员与编译器合作，挑战他的数据库可能会对你的职业生涯有不利的影响… ）。
当然，他的巨大技能给了他一个关于发展问题和项目pipe理解决scheme的独特视angular：虽然VB编写的标准并不完全是严格意义上的标准，但VB王却经常对他所尝试的“编码标准”和“最佳实践”往往成功）强加给我们。 例如：
-
所有的C / C ++数组应该从索引1开始，而不是从0开始。实际上，使用0作为数组的第一个索引已经过时了，而且已经被Visual Basic 6深入的数组索引pipe理所取代。
-
所有函数都会返回一个错误代码：在VB6中没有例外，为什么我们需要它们呢？ （ 即在C ++中 ）
-
由于“所有函数都返回一个错误代码”对于返回有意义types的函数是不实用的，所以所有函数都应该有一个错误代码作为第一个[input/输出]参数。
-
我们所有的代码都会检查错误代码（ 这导致了VBScript if-indentation在我的职业生涯中遇到过的最糟糕的情况……当然，由于“else”子句从来没有处理过，所以没有发现任何错误，直到太迟 ）。
-
由于我们正在使用C ++ / COM，从今天开始，我们将在Visual Basic中编写我们所有的DOM实用程序函数。
-
ASP 115错误是邪恶的。 为此，我们将在VBScript / ASP代码中使用On Error Resume Next来避免它们。
-
XSL-T是一种面向对象的语言。 使用inheritance来解决你的问题（ 愚蠢的惊喜几乎打破了我的下巴打开这一天 ）。
-
例外情况没有被使用，因此应该被删除。 因为这个原因，我们将取消选中要求析构函数调用的checkbox，以便在exception解除的情况下（ 专家找了所有这些内存泄漏的原因花了几天的时间，当他发现他们已经自愿忽略时，他几乎是疯了）隐藏）关于再次检查选项的技术说明，几个星期前发送 ）。
-
捕获我们的COM模块的COM接口中的所有exception，并静静地处理它们（ 这样，而不是崩溃，模块只会看起来更快…shiny！…正如我们使用上述error handling，它甚至花了我们一些时间来了解真正发生了什么事情……你不能既有速度又有正确的结果，你能吗？
-
从今天开始，我们的代码库将分成四个分支。 我们将pipe理他们的同步，并手动整合所有错误修正/演变。
除了C / C ++数组 ， VB DOM实用函数和XSL-T作为OOP语言之外 ，所有人都实施了抗议活动。 当然，一段时间以后，一些被发现， 呃 ，被打破，完全放弃。
当然， VB国王的信誉从来没有受到过这样的伤害：在高层pipe理人员中，他一直是“顶尖枪”技术专家。
这产生了一些有趣的副作用，你可以通过下面的链接看到什么是你遇到的源代码中的最好的评论？
回到80年代/ 90年代，我曾在一家使用FORTRAN的飞机模拟器公司工作。 我们的FORTRAN编译器对variables名称有8个字符的限制。 该公司的编码标准保留了前三个匈牙利符号风格的信息。 所以我们不得不尝试用5个字符创build有意义的variables名称！
我曾在两家公司合并过的地方工作过。 “主导”的有一个用K＆R C编写的主要服务器（即，在ANSI之前）。 他们迫使Java团队（来自两个办公室 – 可能总共有20个开发者）使用这种格式，高兴地忽略了“支撑辩论”的两个支柱，并直接疯狂：
if ( x == y ) { System.out.println("this is painful"); x = 0; y++; }
禁止：
while (true) {
允许：
for (;;) {
我的一个朋友 – 我们会称他为CodeMonkey–在他的第一份工作是从大学（ 许多年前）在COBOL进行内部开发。 他的第一个程序被拒绝为“不符合我们的标准”，因为它使用了嵌套的IF语句（不寒而栗）
编码标准禁止使用嵌套的IF语句
现在，CodeMonkey并不害羞，而且他的能力也是确定的，所以他坚持要求每个人都在连锁店里，为什么这个规则存在。 大多数人声称他们不知道，有些人编造了关于“可读性”的东西，最后一个人记得原来的原因：他们使用的第一个版本的COBOL编译器有一个bug，并没有正确处理嵌套的IF语句。
这个编译器错误当然已经修复了至less十年，但没有人对这个标准提出质疑 。 [咩咩咩！]
CodeMonkey成功地改变了标准 – 最终！
曾经在禁止下划线的项目上工作。 我的意思是完全禁止。 所以在ac＃winforms应用程序中，每当我们添加一个新的事件处理程序（例如一个button）时，我们必须将buttonName_Click（）中的默认方法名称重命名为其他字符，以满足编写代码的人的自我标准。 直到今天，我不知道他对这个卑微的下划线有什么反对
完全无用的数据库命名约定。 每个表名都必须以数字开头。 这些数字显示了哪种数据在表格中。
- 0：无处不在的数据
- 1：仅由某个模块使用的数据
- 2：查找表
- 3：日历，聊天和邮件
- 4：伐木
如果只知道名字的第一个字母，就很难find表格。 另外 – 因为这是一个mssql数据库 – 我们必须将表名与方括号无处不在。
-- doesn't work select * from 0examples; -- does work select * from [0examples];
我们正在做一个C ++项目，团队领导是一个Pascal人。
所以我们有一个编码标准include文件来重新定义所有讨厌的C和C ++语法：
#define BEGIN { #define END }
但是等等还有更多！
#define ENDIF } #define CASE switch
毕竟这个时候很难记住。
这取得了完美可读的C ++代码，除了团队领导以外，任何人都难以辨认。
我们还必须使用反向匈牙利符号，即
MyClass *class_pt // pt = pointer to type UINT32 maxHops_u // u = uint32
虽然奇怪，我渐渐喜欢这个。
在以前的工作上：
- “正常”表格以T_开头
- “系统”表（通常是查找）以TS_开始（除非他们不是因为有人不喜欢那一天）
- 交叉引用表以TSX_开头
- 所有字段名称都以F_开头
恩，那就对了。 所有的字段，在每个表中。 所以我们可以告诉它是一个领域。
我的一个哥们在政府工作时遇到这个规则。 ++（pre或post）的使用被完全禁止。 原因：不同的编译器可能会有不同的解释。
一半的球队喜欢四格缩进; 另一半则赞成双空间缩进。
正如你所猜测的那样，编码标准规定了三个，以“平等冒犯”（直接引用）。
作为经理声称它不能使用reflection太多“魔术”。
我有一个非常奇怪的东西，一个花了我很长时间来推翻，是当我们公司的所有者要求我们的新产品只有IE浏览器。 如果它可以在FireFox上工作，那也没关系，但它只能是IE浏览器。
这听起来可能不太奇怪，除了一点小小的缺陷。 所有的软件都是在Linux上运行的一个定制的服务器软件包，我们客户购买的所有客户端软件都是Linux。 没有试图弄清楚如何让Wine（在那些日子里，非常不可靠）在所有这些盒子上运行起来，看看我们是否可以让IE运行，并培训他们的pipe理员如何debugging葡萄酒问题，这根本不可能满足业主的要求。 问题是，他正在做网页devise，只是不知道如何使网站符合FireFox。
知道我们公司破产了可能不会让你震惊。
使用通用编号标识符名称
在我目前的工作中，我们有两条真正意义的规则：
规则1：每当我们在数据库表中创build一个新的字段时，我们必须添加额外的保留字段以供将来使用。 这些保留字段被编号（因为没有人知道哪些数据，他们将有一天举行）下一次，我们需要一个新的领域，我们首先寻找一个未使用的保留字段。
因此，我们最终以customer.reserve_field_14包含customer.reserve_field_14的电子邮件地址。
有一天，我们的老板想着介绍储备表 ，但是我们可以说服他不要这样做。
规则2：我们的产品之一是用VB6编写的，而VB6有不同的标识符名称总数的限制，而且由于代码非常大，我们经常遇到这个限制。 作为一个“解决scheme”，所有的本地variables名都被编号：
-
Lvarlong1 -
Lvarlong2 -
Lvarstr1 - …
虽然这有效地规避了标识符的限制，但是这两个规则相结合导致了漂亮的代码如下：
... If Lvarbool1 Then Lvarbool2 = True End If If Lvarbool2 Or Lvarstr1 <> Lvarstr5 Then db.Execute("DELETE FROM customer WHERE " _ & "reserve_field_12 = '" & Lvarstr1 & "'") End If ...
你可以想象修复旧的或其他人的代码是多么困难…
最新更新：现在我们也在为私人会员使用“预备程序”
Private Sub LSub1(Lvarlong1 As Long, Lvarstr1 As String) If Lvarlong1 >= 0 Then Lvarbool1 = LFunc1(Lvarstr1) Else Lvarbool1 = LFunc6() End If If Lvarbool1 Then LSub4 Lvarstr1 End If End Sub
编辑：看来，这种代码模式变得越来越stream行。 看到这个每日跆拳道职位了解更多： 散光 🙂
回到我的C ++时代，我们不允许使用==，> =，<=，&&等，这里有macros…
if (bob EQ 7 AND alice LEQ 10) { // blah }
这显然是要处理“有条件错误的旧意外分配”，但是我们也有“把常量放在variables之前”的规则，所以
if (NULL EQ ptr); //ok if (ptr EQ NULL); //not ok
只记得，我听过的最简单的编码标准是“编写代码，好像下一个维护者是一个知道你住在哪里的恶毒精神病患者”。
Hungarian notation in general.
I've had a lot of stupid rules, but not a lot that I considered downright strange.
The sillyiest was on a NASA job I worked back in the early 90's. This was a huge job, with well over 100 developers on it. The experienced developers who wrote the coding standards decided that every source file should begin with a four letter acronym, and the first letter had to stand for the group that was responsible for the file. This was probably a great idea for the old FORTRAN 77 projects they were used to.
However, this was an Ada project, with a nice hierarchal library structure, so it made no sense at all. Every directory was full of files starting with the same letter, followed by 3 more nonsense leters, an underscore, and then part of the file name that mattered. All the Ada packages had to start with this same five-character wart. Ada "use" clauses were not allowed either (arguably a good thing under normal circumstances), so that meant any reference to any identifier that wasn't local to that source file also had to include this useless wart. There probably should have been an insurrection over this, but the entire project was staffed by junior programmers and fresh from college new hires (myself being the latter).
A typical assignment statement (already verbose in Ada) would end up looking something like this:
NABC_The_Package_Name.X := NABC_The_Package_Name.X + CXYZ_Some_Other_Package_Name.Delta_X;
Fortunately they were at least enlightened enough to allow us more than 80 columns! Still, the facility wart was hated enough that it became boilerplate code at the top of everyone's source files to use Ada "renames" to get rid of the wart. There'd be one rename for each imported ("withed") package. 喜欢这个：
package Package_Name renames NABC_Package_Name; package Some_Other_Package_Name renames CXYZ_Some_Other_Package_Name; --// Repeated in this vein for an average of 10 lines or so
What the more creative among us took to doing was trying to use the wart to make an acutally sensible (or silly) package name. (I know what you are thinking, but explitives were not allowed and shame on you! That's disgusting). For example, I was in the C ommon code group, and I needed to make a package to interface with the W orkstation group. After a brainstorming session with the Workstation guy, we decided to name our packages so that someone needing both would have to write:
with CANT_Interface_Package; with WONT_Interface_Package;
When I started working at one place, and started entering my code into the source control, my boss suddenly came up to me, and asked me to stop committing so much. He told me it is discouraged to do more than 1 commit per-day for a developer because it litters the source control. I simply gaped at him…
Later I understood that the reason he even came up to me about it is because the SVN server would send him (and 10 more high executives) a mail for each commit someone makes. And by littering the source control I guessed he ment his mailbox.
Doing all database queries via stored procedures in Sql Server 2000. From complex multi-table queries to simple ones like:
select id, name from people
The arguments in favor of procedures were:
- 性能
- 安全
- Maintainability
I know that the procedure topic is quite controversial, so feel free to score my answer negatively 😉
There must be 165 unit tests (not necessarily automated) per 1000 lines of code. That works out at one test for roughly every 8 lines.
Needless to say, some of the lines of code are quite long, and functions return this pointers to allow chaining.
We had to sort all the functions in classes alphabetically, to make them "easier to find". Never mind the ide had a drop down. That was too many clicks.
(same tech lead wrote an app to remove all comments from our source code).
In 1987 or so, I took a job with a company that hired me because I was one of a small handful of people who knew how to use Revelation. Revelation, if you've never heard of it, was essentially a PC-based implementation of the Pick operating system – which, if you've never heard of it, got its name from its inventor, the fabulously-named Dick Pick. Much can be said about the Pick OS, most of it good. A number of supermini vendors (Prime and MIPS, at least) used Pick, or their own custom implementations of it.
This company was a Prime shop, and for their in-house systems they used Information. (No, that was really its name: it was Prime's implementation of Pick.) They had a contract with the state to build a PC-based system, and had put about a year into their Revelation project before the guy doing all the work, who was also their MIS director, decided he couldn't do both jobs anymore and hired me.
At any rate, he'd established a number of coding standards for their Prime-based software, many of which derived from two basic conditions: 1) the use of 80-column dumb terminals, and 2) the fact that since Prime didn't have a visual editor, he'd written his own. Because of the magic portability of Pick code, he'd brought his editor down into Revelation, and had built the entire project on the PC using it.
Revelation, of course, being PC-based, had a perfectly good full-screen editor, and didn't object when you went past column 80. However, for the first several months I was there, he insisted that I use his editor and his standards.
So, the first standard was that every line of code had to be commented. Every line. No exceptions. His rationale for that was that even if your comment said exactly what you had just written in the code, having to comment it meant you at least thought about the line twice. Also, as he cheerfully pointed out, he'd added a command to the editor that formatted each line of code so that you could put an end-of-line comment.
Oh, yes. When you commented every line of code, it was with end-of-line comments. In short, the first 64 characters of each line were for code, then there was a semicolon, and then you had 15 characters to describe what your 64 characters did. In short, we were using an assembly language convention to format our Pick/Basic code. This led to things that looked like this:
EVENT.LIST[DATE.INDEX][-1] = _ ;ADD THE MOST RECENT EVENT EVENTS[LEN(EVENTS)] ;TO THE END OF EVENT LIST
(Actually, after 20 years I have finally forgotten R/Basic's line-continuation syntax, so it may have looked different. But you get the idea.)
Additionally, whenever you had to insert multiline comments, the rule was that you use a flower box:
************************************************************************ ** IN CASE YOU NEVER HEARD OF ONE, OR COULDN'T GUESS FROM ITS NAME, ** ** THIS IS A FLOWER BOX. ** ************************************************************************
Yes, those closing asterisks on each line were required. After all, if you used his editor, it was just a simple editor command to insert a flower box.
Getting him to relent and let me use Revelation's built-in editor was quite a battle. At first he was insistent, simply because those were the rules. When I objected that a) I already knew the Revelation editor b) it was substantially more functional than his editor, c) other Revelation developers would have the same perspective, he retorted that if I didn't train on his editor I wouldn't ever be able to work on the Prime codebase, which, as we both knew, was not going to happen as long as hell remained unfrozen over. Finally he gave in.
But the coding standards were the last to go. The flower-box comments in particular were a stupid waste of time, and he fought me tooth and nail on them, saying that if I'd just use the right editor maintaining them would be perfectly easy. (The whole thing got pretty passive-aggressive.) Finally I quietly gave in, and from then on all of the code I brought to code reviews had his precious flower-box comments.
One day, several months into the job, when I'd pretty much proven myself more than competent (especially in comparison with the remarkable parade of other coders that passed through that office while I worked there), he was looking over my shoulder as I worked, and he noticed I wasn't using flower-box comments. Oh, I said, I wrote a source-code formatter that converts my comments into your style when I print them out. It's easier than maintaining them in the editor. He opened his mouth, thought for a moment, closed it, went away, and we never talked about coding standards again. Both of our jobs got easier after that.
At my first job, all C programs, no matter how simple or complex, had only four functions. You had the main, which called the other three functions in turn. I can't remember their names, but they were something along the lines of begin(), middle(), and end(). begin() opened files and database connections, end() closed them, and middle() did everything else . Needless to say, middle() was a very long function.
And just to make things even better, all variables had to be global.
One of my proudest memories of that job is having been part of the general revolt that led to the destruction of those standards.
An externally-written C coding standard that had the rule 'don't rely on built in operator precedence, always use brackets'
Fair enough, the obvious intent was to ban:
a = 3 + 6 * 2;
in favour of:
a = 3 + (6 * 2);
Thing was, this was enforced by a tool that followed the C syntax rules that '=', '==', '.' and array access are operators. So code like:
a[i].x += b[i].y + d - 7;
had to be written as:
((a[i]).x) += (((b[i]).y + d) - 7);
