理智与隐形标记
制表符与空格
隐形和近乎隐形的标记将我们带到了问题的“人”的部分——并不是说代码编辑器作者不是人，但我们大多数人不会编写新的编辑器，尽管我们所有人都会使用编辑器。 众所周知，曾经有一段时间计算机的内存很小，制表符（单字节）与相应数量的空格（8 个）之间的差异可能是存储在珍贵磁盘上的源代码大小以及通过任何原始且缓慢的总线从存储器传输到内存中的源代码大小之间的显着差异。
被称为意大利面条式代码的淫秽耦合
教你的初级程序员如何阅读代码
由于你们都在同一个代码库上工作，因此您也有充足的机会通过向这个人展示您的编码方式来发挥领导作用。 您必须小心地执行此操作，否则初级程序员会认为您是在摆架子，但是，通过一点温柔的展示和讲解，您可以让您的 Padawan 明白您的意图。 对于我们这些喜欢与看似逻辑的机器共度时光的人来说，这种人际互动通常很困难。
我们计算所用的隐喻
代码是一个故事，解释了如何解决特定问题。
程序员必须能够用他们的代码讲述故事，解释他们如何解决特定问题。 像作家一样，程序员必须了解他们的隐喻。 许多隐喻都能解释一个概念，但您必须有足够的技能来选择正确的隐喻，以便将您的想法传达给未来将阅读该代码的程序员。 因此，您不能使用您知道的每一个隐喻。 您必须掌握隐喻选择的艺术，即意义的放大。 您必须知道何时添加以及何时删除。 您将学会像作家一样修改和重写代码。 一旦没有什么可添加或删除的，您就完成了您的工作。
软件开发的不圣洁三位一体
测试、文档和代码
这样的问题让人想起源代码、文档和测试是软件开发的不圣洁三位一体，尽管许多组织喜欢将它们视为独立的实体。 有趣的是，虽然许多团体口头上赞成“测试驱动开发”，但他们并没有将文档包含在 TDD 中。
代码囤积
提交到提交，以及总结图表的美妙之处
亲爱的 KV，为什么开源项目的这么多有用功能都隐藏在晦涩的配置选项下，这意味着它们几乎不会被使用？ 这仅仅是典型的文档和推广不力，还是有什么东西让这些开发人员隐藏他们的代码？ 似乎代码并没有损坏。 当我在最近遇到的一些代码中打开这些功能时，系统在测试和生产中仍然保持稳定。 我认为代码应该要么被使用，要么从系统中删除。 如果代码在源代码存储库中，那么它并没有真正丢失，但它也没有使系统的其余部分变得混乱。
拉撒路代码
没有人会想到西班牙宗教裁判所。
我被要求调查是否有可能使用一个 15 年前的开源软件并对其进行更新，使其可以在我公司当前使用的系统上工作。 代码本身似乎还不错，至少不比我习惯阅读的代码差，但我怀疑从头开始编写新版本可能比尝试理解我没有编写且多年无人积极维护的代码更容易。
代码滥用
一个程序员的扩展是另一个程序员的滥用。
在最近的工作停机期间，我一直在清理一组库，删除死代码，更新文档块，并修复一些烦人但不关键的小错误。 这段代码探险揭示了一些库不仅被使用，而且还被滥用了。 每个人和他们的姐妹都将计时库用于他们能想到的几乎任何事件这一事实还算不错，因为它是一个旨在定期调用代码的库（尽管某些事件似乎根本不需要成为事件）。
更多代码意味着更少错误吗？
你今天节省的字节可能会在明天咬你一口
亲爱的 One，你几乎用你对简洁的呼吁说服了我，即在上面使用 system() 的单行代码减少了出现错误的可能性。 几乎，但还差一点。
一段不错的代码
生动的隐喻和正确地重用函数
在上一期 Kode Vicious（系统不是产品，《》10 (4)，2012 年 4 月）中，我提到我最近阅读了两段实际上降低而不是升高我的血压的代码。 正如承诺的那样，本期 KV 涵盖了第二段代码。
我的编译器不理解我
在我们编程语言赶上之前，代码将充满恐怖。
直到最近，许多聪明的人才找到了听众，就我们编码的内容和方式提出了合理的观点。 各种同事多年来一直在敲锣打鼓，试图确保关于编程的明智见解能够深入人心。 本刊和其他出版物上关于编码风格的文章进一步提供了此类倡导的例子。
系统不是产品
在浪费时间重新输入配置数据之前，停下来闻闻代码的味道
偶尔，我会遇到一段不错的代码，并想花点时间来认识到这个事实，哪怕只是为了在每年的体检之前保持低血压。 第一个引起我注意的代码是 Linux 中的 clocksource.h。 Linux 通过一组像俄罗斯套娃一样组合在一起的结构与硬件时钟（例如主板上的晶体）接口。
超维度焦油坑
猜一个数字，将数字加倍，然后移动到下一个更大的时间单位。
当我 25 多年前开始从事计算机工作时，一位年长的同事给了我一个经验法则来估计我何时才能正确完成一项任务：猜一个数字，将数字加倍，然后移动到下一个更大的时间单位。 这个规则以一种非常有趣的方式缩放任务：一项一分钟的任务爆炸了 120 倍，需要两个小时才能完成。 一项一小时的工作“仅”爆炸了 48 倍，需要两天才能完成，而一项一天的工作增长了 14 倍，需要两周才能完成。
代码旋耕
KV 讨厌不必要的工作。
亲爱的 KV，每当与我一起工作的某个程序员需要在函数中添加一个变量并且名称与先前使用的名称冲突时，他都会将所有先前的实例更改为新的不同名称，以便他可以自己重用该名称。 这导致他的差异比他们需要的要大得多，并且让我非常恼火。 每当我在这方面挑战他时，他都会说旧的用法无论如何都是错误的，但我认为那只是他在找借口。
编码指南：在科学中发现艺术
是什么将好的代码与伟大的代码区分开来？
计算机科学既是一门科学，也是一门艺术。 它的科学方面范围从计算理论和算法研究到代码设计和程序架构。 然而，当涉及到实施时，艺术天赋、细致入微的风格和技术实力的结合将好的代码与伟大的代码区分开来。
面对不确定的过去
借口，借口，借口！
使用我最喜欢的希腊语被动-现在-中性分词（我相信您也有一个），我对这个迟来的专栏提出了戏剧性的导言。 即，对其迟到的道歉和解释。 （您会注意到潜在的无限递归，因为专栏和借口都迟到了。）道歉很容易：我们英国人只是说“非常抱歉，实际上”，并表现出痛苦的诚意，无论我们是否真心实意。
粉刷自行车棚
一种结束毫无意义的编码辩论的万无一失的技术
上周，我们一位较新的工程师签入了一个简短的程序，以帮助调试我们正在开发的代码中的问题。 即使这是一个测试程序，也有几个人阅读了代码，然后对他们希望看到的更改发表了评论。 代码没有任何重大问题，但对于正在签入的内容，它似乎产生了大量电子邮件。 最终，线程中的评论比程序本身还要长。 在线程中的某个时刻，提交代码的程序员说，“听着，我已经签入了代码； 你现在可以把你想要的任何颜色粉刷自行车棚了，”然后拒绝再对代码进行任何更改。
自然的缺陷
以及优柔寡断的危险。 Stan Kelly-Bootle 的最新思考。
多栏的想法像希腊神庙一样潜伏在我所谓的头脑中，直到 2008 年结束。 有太多年度新闻陈词滥调可用，回顾我们过去一年中的所有错误，并决心永远不要在 2009 年重蹈覆辙。 我现在必须发泄的一个烦恼：我们可以禁止诸如“X 比你想象的要糟糕得多”这样的空洞结构吗？ 或者“Y 比许多人想象的要简单得多”？ 我们可能从未以这种或那种方式想到 X，或者对 Y 的易用性做出假设，但我们倾向于点头并继续前进，就好像已断言了一些有意义的主张； 更糟糕的是，某些判断已经得到无可争议的验证。
代码探险重制版
这个主题是否重要到值得在五年内发表两篇文章？ 我认为是。
自从我第一次撰写关于代码探险的文章以来已经五年了，尽管系统的大小和范围不断增长，但我们用来理解这些系统的工具并没有以相同的速度增长。 事实上，我认为我们正在稳步失守。 那么我们为什么要重蹈覆辙呢？ 这个主题是否重要到值得在五年内发表两篇文章？ 我认为是。
务实地对待实时
亲爱的 KV，我正在开发一个对时序问题非常敏感的网络系统。
我正在开发一个对时序问题非常敏感的网络系统。 当系统首次开发时，带宽要求完全在现成的硬件和软件的容忍度范围内，但在过去三年中，情况发生了变化。 数据流保持不变，但现在系统被要求对事件的到达做出更快的反应。 该系统是用 C++ 编写的，并在 Linux 之上运行。 在最近的项目会议上，我建议减少延迟的最快方法是转移到 Linux 的实时版本，因为实时操作系统旨在为应用程序提供最低延迟的服务。
仿射浪漫
买家（和卖家）当心
有一个英国成语“Suck it and see”，是怀疑论的缩影，尽管其简洁粗俗，但完全可以取代关于现实结构的整部哲学大作。 一个不那么激进的版本是“给我看，我来自密苏里州”，这需要正确的南方密苏里州拖腔才能产生最大的影响。 无论您来自哪里，其信息都是在面对花哨的主张时保持永恒的警惕。
美丽的代码确实存在，如果您知道在哪里寻找
一个有态度的 koder，KV 回答您的问题。 他不是 Manners 小姐。
我已经阅读您的咆哮有一段时间了，我不禁要问，您真的喜欢任何代码吗？ 您似乎总是如此消极； 我真的很想知道您是否真的相信编程世界是如此丑陋的地方，或者在某个地方，是否存在您会去但从未告诉读者的快乐之地。
美丽的代码确实存在，如果您知道在哪里寻找
一个有态度的 koder，KV 回答您的问题。 他不是 Manners 小姐。
我已经阅读您的咆哮有一段时间了，我不禁要问，您真的喜欢任何代码吗？ 您似乎总是如此消极； 我真的很想知道您是否真的相信编程世界是如此丑陋的地方，或者在某个地方，是否存在您会去但从未告诉读者的快乐之地。
美丽的代码确实存在，如果您知道在哪里寻找
一个有态度的 koder，KV 回答您的问题。 他不是 Manners 小姐。
我已经阅读您的咆哮有一段时间了，我不禁要问，您真的喜欢任何代码吗？ 您似乎总是如此消极； 我真的很想知道您是否真的相信编程世界是如此丑陋的地方，或者在某个地方，是否存在您会去但从未告诉读者的快乐之地。
只有代码有价值？
即使是写得最好的代码也无法揭示它为什么要做它正在做的事情。
最近一次关于开发方法的对话转向了开发过程中产生的各种工件的相对价值，与我交谈的人说：代码“一直是唯一重要的工件。 只是我们现在才开始认识到这一点。” 我当时没有表达的反应是双重的。 首先，我很有似曾相识的感觉，因为它让我想起了我读本科的时候，以及关于代码是否是自文档化的许多激烈讨论的回忆。
所罗门的剑胜过奥卡姆剃刀
选择您最佳的假设
我已经告诉过你一古戈尔次或更多次：不要夸大！ 而且，较少情况下，我曾经委婉地敦促你不要低估。 为什么我的建议被忽略了？ 为什么你不能把它弄对……恰到好处，平衡到无可争议？ 正如我妈妈常说的，Lez Joosts Mildews，用同样的奉献精神打我的两只耳朵。 遵循道在他中王国所做的那样走中庸之道。 或者“直截了当”，正如高尔夫球手 Bing Crosby 曾经吟唱的那样。 他的另一首高尔夫歌曲是“The Wearing of the Green”，但这种题外话与我直截了当、勇往直前的建议背道而驰。
万物平等？
新年，新的视角
当这些漂亮的文字到达您手中时，崭新的一年即将到来。 又一年！ 又一次猛烈的打击！ 正如丁尼生雷鸣般说道。 或者正如 Humphrey Lyttelton (q.g.) 可能会说，“时间可憎的里程表又滴答一声，记录了熵酷刑的又一个棘轮。” 不那么异想天开的是，除了努力不在我们的支票上写 2007 年之外，我们中的许多人还将借此机会反思我们去年所做的所有愚蠢的事情，并决心不再做它们。 更不用说我们未能做的所有好事了。 我想到了我错过一个必不可少的分号的时候，以及插入一个虚假分号同样是灾难性的时候。
有毒的程序员
一个有态度的 koder，KV 回答您的问题。 他不是 Manners 小姐。
亲爱的 KV，我希望您不介意我问您一个与工作无关的问题，尽管我想如果您介意，您就不会回答。 当我有时间时，我会参与一个开源项目，并且我们遇到了一些令人讨厌的非技术问题。 这些问题实际上是人，我想您知道我指的是哪些人：那些经常与其他项目成员为似乎最琐碎的点争吵的人，或者那些对项目贡献很少但似乎需要大量帮助来满足其特定需求的人。 我发现自己认为，如果这些人走了就好了，但我不认为就这些事情在我们的邮件列表中发起一场口水战真的会有所帮助。
用进废退
抽象的格言
我的每日格言允许我在许多方向上广泛漫游，我希望其中一些对于 Queue 的读者来说是及时且具有启发意义的。 我选择法语格言是一种理所当然的精英主义姿态，向蒙田、伏尔泰、Bertrand Meyer 和那个优雅的人群致敬。 Gallic gargled r（如 Brassens 中的 r）和崇高的长尾音节，如果你发音正确，与英语双元音的草率序列相比，简直是优雅：a-for-iz-um。 我们倾向于将术语格言和警句视为格言、座右铭甚至谚语的豪华同义词。
代码错觉
真实的、抽象的和感知的
不，我不是在兑现利用畅销书的标题多米诺骨牌效应。 考虑到容易上当受骗的读者带来的丰厚回报，诱惑是巨大的，但在正派作家的心目中，文学搭便车的耻辱抵消了这种诱惑。 因此，卢浮宫指南变成了《达芬奇密码傻瓜漫步指南》，可以说，在一本书的封面上挤奶了几头热牛。 同样，传统的食谱书也以诸如《达芬奇食谱——为信徒准备的 Opus Dei 食谱》等标题来提升。 丹·布朗的伪小说销售统计数据继续令人惊叹，巧妙地受到剽窃指控和随后的诉讼的刺激。
下一个大事件
函数式编程的未来和 KV 的五大协议设计技巧
亲爱的 KV，我知道您之前写过一篇文章，其中列出了一些要阅读的书籍。 我还会考虑添加《如何设计程序》，该书可在网上免费获得。 这本书非常适合解释编写程序的过程。 它使用 Scheme 语言并介绍了 FP。 我认为 FP 可能是编程的未来。 IBM 研究实验室的 John Backus 在 1977 年提出了这一点。 甚至微软也通过在 C# 中引入 FP 概念以及 LINQ 而屈服于 FP。
地面控制呼叫建筑师汤姆……
你能听到我说话吗？
项目经理喜欢他，最近的软件工程毕业生向他鞠躬，他激励了开发战壕深处的代码战士，让他们怀疑技术时间扭曲是否可能已经掠过了他们。 建筑师汤姆所宣扬的软件开发的简单性、创新性和自动化是前所未有的，这怎么可能呢？ 他的想法听起来如此具有太空时代感，如此具有未来感，但这有什么好奇怪的呢？ 毕竟，汤姆是一位建筑宇航员！
有些天鹅是黑色的
……以及其他灾难
您很可能从我的标题中期望我即将深入探讨纳西姆·尼古拉斯·塔勒布关于灾难和准经验随机性的理论。 反过来，我也希望您已经阅读了塔勒布的畅销书《黑天鹅——高度不可能事件的影响》，该书探讨了生活中固有的不确定性以及如何预期甚至应对意外事件。
颂歌还是代码？ 程序员们，缪斯女神附体吧！
你的代码是识字的还是文学的？
我这个坏脾气的月份的布道经文是马特·巴顿的文章“计算机编程的精湛技艺”，他在文章中赞扬了被广泛称为文学编程的美德。 与文学和文学等相关术语一样，我们有充足的空间进行神学强度的争论，并通过问题中固有的争议进一步放大：“计算机科学是科学还是艺术？” 和“程序员需要知道什么？” 正如我们必须喜欢敏捷编程而不是笨拙编程一样，很难否定任何识字的东西。
给新手的建议
一个有态度的 koder，KV 回答您的问题。 他不是 Manners 小姐。
亲爱的 KV，我是编程新手，刚刚开始阅读一些关于编程的书籍，特别是 C++ 和 Visual Basic。 我真的很喜欢编程，以至于在过去的几个月里，我从未有一天不编写一些代码。 我现在主要关心的是编程世界为程序员准备了什么。 如果一个人被称为程序员（即，专业人士），他或她真的会编程什么？ 就像，您总是会发明新软件还是什么？ 这主要是在不为他人工作的情况下。
真正的机器人会站起来吗？
从 EDSAC 到 iPod——预测让我们难以捉摸
当被问及自 20 世纪 50 年代我第一次哄骗剑桥 EDSAC 进入阵阵计算飞跃以来，哪些计算技术的进步最让我眼花缭乱时，我必须承认，苹果的 iPod 概括了在一个令人惊叹的标志性小工具中的许多不可预见的奇迹。 与那些在摇晃几次后收集灰尘的电动鼻毛修剪器和胡椒盐研磨器不同，我的 iPod 实际上就像一个多才多艺的情人一样，在床上和床外，在路上和路上，在我的心脏附近，除非它在我家中的盗版行为中充电和下载。
骑上马鞍，有抱负的代码骑师
一个有态度的 koder，KV 回答您的问题。 他不是 Manners 小姐。
亲爱的 KV，我是一名 IT 顾问/承包商。 我主要从事网络和 Microsoft 操作系统方面的工作。 我已经从事这项工作八年多了。 不幸的是，它开始让我感到厌烦。 我的问题是：我如何才能重新开始编程？ 我说重新开始是因为我有一些经验。 在高中时，我参加了两门 Applesoft BASIC 编程课程。 我很喜欢它，在所有方面都做得很好，并且是老师见过的最好的编程学生。 这激发了我对计算机科学的兴趣，我在大学里追求了计算机科学。 在大学里，我参加了 C++、Java 和 Web 开发课程。
面对压力
一个有态度的 koder，KV 回答您的问题。 他不是 Manners 小姐。
亲爱的 KV，我一直在一个软件团队工作，该团队在几个不同的操作系统平台上生成最终用户应用程序。 我最初是一名构建工程师，负责设置构建系统，然后是夜间测试脚本，现在我从事几个组件本身的工作，以及维护构建系统。 我在构建软件时看到的最大问题是 API 缺乏稳定性。 当添加新 API 时，这没关系——如果您愿意，可以忽略这些 API——并且当删除 API 时，我知道，因为构建会中断。 最大的问题是当有人更改 API 时，因为这要到某个测试脚本（或更糟糕的是，用户）执行代码并崩溃时才会发现。
银弹呼啸而过的软件开发……
可能需要致电特兰西瓦尼亚。
软件行业的资深人士会证明，他们在自己的时代已经看到了许多银弹的出现和消失。 昨天的银弹，例如 OO、高级软件语言和 IDE，现在显然只是与今天发射的精银相比的低级合金。 例如，今天的银弹已经展示了为文本和图表提供隐式无与伦比的能力、改变软件开发经济学的能力以及改变长期建立的工程学科焦点的能力。
形式上称为 Pi 的微积分
关于 pi 演算的炒作
多米尼克·比汉曾在一次罕见的清醒时刻问我：“如果你知道某件事，但其他人不知道你知道这件事，那有什么意义呢？” 对此，我用熟悉的口吻回答说，“重要的不是你不知道什么，而是你认为你知道但实际上并非如此的事情。” 在阅读 Stephen Sparkes 在 2006 年 3 月的《》杂志上对 Steve Ross-Talbot 的采访时，我想起了这些可疑的认识论观察。
但是，话虽如此，……
80% 的有用工作由 20% 的代码完成。
编程行业中一个持久的经验法则是 80/20 规则：“80% 的有用工作由 20% 的代码完成。” 与汽油里程一样，您的性能统计数据可能会有所不同，并且考虑到拇指等身体部位的测量不确定性，您可能更喜欢 90/10 的劳动分工。 对于一些臃肿的代码生成元框架，愤世嫉俗者提出了 99/1 规则——如果您能找到那疯狂的 1%。 无论比例如何，这个概念已被证明在性能调整中很有用。
任何数独，我都能做得更好
来自日本的新谜题热潮正在席卷全球，并测试我们的布尔逻辑。
我将这篇文章献给 Jef Raskin 以表纪念。 比我所能收集的更权威的悼词仍在涌入，毫无疑问，那些钦佩这位杰出博学家的人将很快出版一本光荣的纪念文集。 “Le don de vivre a passé dans les fleurs。”
为代码而编码
模型能否为软件开发提供 DNA？
尽管工业界和学术界在 UML（统一建模语言）等建模标准上投入了大量精力，但软件建模长期以来在商业软件开发中发挥着次要作用。 尽管建模通常被认为是最先进的技术，因此是应该做的事情，但随着软件项目从早期的更概念性阶段发展到实际手工制作的阶段，人们对建模的欣赏似乎逐渐减弱。
句法海洛因
一种危险的编码成瘾，会导致可读性灾难。
用户定义的重载是一种毒品。 起初，它给你一种快速、感觉良好的修复。 没有必要用冗长而丑陋的函数名称（如 IntAbs、FloatAbs、DoubleAbs 或 ComplexAbs）来搞乱代码； 只需将它们都命名为 Abs。 更好的是，使用代数表示法，例如 A+B，而不是 ComplexSum(A,B)。 它当然使编码更紧凑。 但危险的成瘾很快就会发生。 已经足够复杂以至于让每个人的能力都捉襟见肘的语言和程序突然变得更加复杂。
归档在“不可知！”下
这是一个艰难的夜晚——证明不存在！
黄页曾经以下列方式做广告：“如果你在这里找不到它，它就不存在。” 我最喜欢的认识论学家 Shannan Hobbes 和我会在深夜深入思考这一主张，通过搜索“正方形圆”、“宠物独角兽”、“冷核聚变”、“最大的素数”、“法国在位秃头国王”和类似的怪癖来测试其有效性，这些怪癖经常在 PhilTrans（哲学交易）中讨论。 我们不断增加的失败——或者，为了快速消除令人震惊的歧义——我们越来越多的“未找到”相当于某种归纳验证（稍后会详细介绍）。 黄页，被认为仅仅是可销售字符串的有限层次结构，并没有太多可以告诉我们偶然的客观存在。
注释比代码更重要
彻底使用内部文档是提高软件质量和加快实施速度的最容易被忽视的方法之一。
在本文中，我采取了一种看似自相矛盾的立场。 我认可一些程序员声称使代码自文档化的技术，并鼓励开发“自动文档”的程序。 然而，我也认为这些方法无法提供可靠且可维护的代码所需的文档。 它们只是一种粗略的辅助手段，即使这样也只能帮助文档的一个或两个方面——不包括最重要的方面。
如果没有 NULL，该字符串将永远不会结束
N 连胜，1 连胜，worra 连胜
我很高兴被邀请在“Curmudgeon”这个粗暴的标题下为“”撰写第三篇专栏文章。 坏脾气通常与快乐无关，无论是稀释的还是全强度的，但在我这个年纪，挥舞毒笔的廉价快感尤其受欢迎，因为讽刺的目标每天都在弹跳，就像烤肉的后起之秀：仅仅是“少年罪犯”，正如坏脾气大师乔治·克拉布 [原文如此] 称呼他们一样。
该死的数字
漂浮在实数世界中的实数
首先，我提醒您，“damnéd”有两个音节，需要莎士比亚式的嘲笑，就像奥利维尔炫耀他的理查三世国王的姿态一样。
阅读、写作和代码
编写可读代码的关键是培养良好的编码风格。
四十年前，当计算机编程是一种个人体验时，对易于阅读的代码的需求并未列入任何优先事项列表。 然而，今天，编程通常是一项基于团队的活动，编写其他人可以轻松理解的代码已成为一种必然。 创建和开发可读代码并不像听起来那么容易。
没有源代码？ 没问题！
如果您必须移植程序，但您只有二进制文件怎么办？
典型的软件开发涉及以下两种过程之一：创建新软件以满足特定需求或修改（维护）旧软件以修复问题或满足新需求。 这些转换发生在源代码级别。 但是，如果问题不是维护旧软件，而是需要创建原始软件的功能副本呢？ 如果源代码不再可用怎么办？