Implementing Regular Expressions. Russ Coxrsc@swtch.com This page collects resources about implementing regular expression search efficiently. Articles and Notes “Regular Expression Matching Can Be Simple And Fast” “Regular Expression Matching: the Virtual Machine Approach” An introduction to submatch tracking during efficient (non-backtracking) NFA-based regular expression matching. Supporting programs: “Regular Expression Matching in the Wild” “Regular Expression Matching with a Trigram Index” “IBM 7094 Cheat Sheet” If you want to read Ken Thompson's original 1968 paper (see below), you'll want to take this with you. “Regular Expressions: Languages, Algorithms, and Software” by Brian W. The cleanest, simplest, backtracking implementation you'll ever see. See also Chapter 9 of The Practice of Programming and Chapter 1 of Beautiful Code. Efficient Implementations RE2 regular expression library Efficient automaton-based implementation of Perl-syntax regular expressions (excluding backreferences).
M. API Design Principles. English Русском One of Qt’s most reputed merits is its consistent, easy-to-learn, powerful API. This document tries to summarize the know-how we’ve accumulated on designing Qt-style APIs. Many of the guidelines are universal; others are more conventional, and we follow them primarily for consistency with existing APIs. Although these guidelines are aimed primarily at public APIs, you are encouraged to use the same techniques when designing internal APIs, as a courtesy to your fellow developers.
You may also be interested to read Jasmin Blanchette’s Little Manual of API Design [.in.tum.de] or its predecessor Designing Qt-Style C++ APIs [doc.qt.digia.com] by Matthias Ettrich. Six Characteristics of Good APIs An API is to the programmer what a GUI is to the end-user. Be minimal A minimal API is one that has as few public members per class and as few classes as possible. Be complete A complete API means the expected functionality should be there. Have clear and simple semantics Be intuitive Good Bad. 10 Technical Papers Every Programmer Should Read (At Least Twice) 10 Technical Papers Every Programmer Should Read (At Least Twice) this is the second entry in a series on programmer enrichment Inspired by a fabulous post by Michael Feathers along a similar vein, I’ve composed this post as a sequel to the original.
That is, while I agree almost wholly with Mr. Feather’s1 choices, I tend to think that his choices are design-oriented2 and/or philosophical. All papers are freely available online (i.e. not pay-walled)They are technical (at times highly so)They cover a wide-range of topicsThe form the basis of knowledge that every great programmer should know, and may already Because of these constraints I will have missed some great papers, but for the most part I think this list is solid.
A Visionary Flood of Alcohol Fundamental Concepts in Programming Languages (link to paper) by Christopher Strachey Quite possibly the most influential set of lecture notes in the history of computer science. Why Functional Programming Matters (link to paper) by John Hughes. Coding Standards. Table of Contents The GNU coding standards, last updated March 31, 2014. Copyright © 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”. 1 About the GNU Coding Standards The GNU Coding Standards were written by Richard Stallman and other GNU Project volunteers.
If you did not obtain this file directly from the GNU project and recently, please check for a newer version. Please send corrections or suggestions for this document to bug-standards@gnu.org. 2 Keeping Free Software Free Or go for generality. » 编程珠玑番外篇-6.高效能编程的七个好习惯 | 4G spaces. 这七条都是我这个不怎么高效能编程的人悟到的. 不权威, 不一定全对. 1. 使用工具帮你找 Bug, 而不是人工找. 工具包括用单元测试, assert语句, 代码测试容器. 人工指用 print 和 debugger 一行一行跟踪. 我们知道, 编程中绝大部分时间是耗费在除 bug 上. 不同的人有不同的 debug 的方法. 单元测试中的红棒绿棒(熟悉 JUnit 的读者知道我在说什么)一出现, 哪里出了问题就一目了然. 一般的语言都有 assert, 但是很少有人用. 这样的 ASSERT 可以带一个信息出来, 比起原来只告诉你哪个文件哪一行更加有价值. 第三个是用容器帮你找 Bug. 2. 用 gcc 或者简单的 IDE 来编译和运行程序在编程初期是很快速的, 可是越到后来, 会越臃肿. 自动化测试也有很多工具, 特别是 GUI 和命令行测试的自动化, 工具链都很完整. 3.
这是大实话. 4. 人月神话的作者 Brooks 说: 准备把第一版扔掉, 因为第一版必然要被扔掉. 所谓的快速原型开发, 大致有两个捷径, 第一是只做核心的功能, 输入输出都是构造好的简单的例子. 即使在代码编写阶段, 一些功能的实现, 也是要先写个简单的, 再慢慢打磨成复杂的. 5. 不知道各位调试程序的时候是不是和我一样, 看到不确定的和要跟踪的变量就直接插入一行 print. 如果必然要输出日志, 最好要分配一个单独的命令行参数, 用来控制程序究竟输出不输出日志, 输出哪些日志. 日志和程序的输出结果一定要清晰且能自我解释, 否则不如没有日志. 更多的关于数据和程序结果要能自我解释的精彩论述, 可参见 More Programming Pearls 第四章. 6. 我发现, 人有一个固有的习惯, 就是喜欢自己去”人工”, 而不喜欢用工具. 别看上面说的这些好像程序员没有, 其实我们常常陷入这个误区. 7. Knuth 名言: Premature optimization is the root of all evil. 在程序能跑的情况下, 优化也要特别小心. 另外: 用两个或者大于两个显示器. » 十年学会程序设计 | 4G spaces. Peter Norvig (Copyright 2001) 原文网址 为何大家如此匆忙? 走进任何一家书店，你会看到书架上一排不见尽头的放着如 <7天自学Java语言> 以及几天或者几小时学会Windows, 因特网或者Visual Basic 这类书。
我在Amazon 网上书店用一下的方式进行高级搜索: 出版年份: 1992以后 书名包括：“天” 和 “学习” 或 “自学” 得到了268条搜索结果，其中前78条都是计算机书（第79条是 30天学会孟加拉语）。 我用 “小时” 代替“天” 作为关键字，得到了神奇般类似的结果：这次有253本书，前77本是计算机书， 第78本是 24小时自学语法和写作风格。 排名前200的书中有96%是计算机书。 由此可见，人们要不就是急着想学会计算机，要不就是计算机相比于其他事情太容易学会了。 让我们分析一下 三天学会Pascal语言 [英文网页] 这样的标题表达了什么意思： 学会: 在 三天内，你没有时间去写几个有意义的程序，或者从成功和失败中学到东西。 Pascal 语言: 三 天内你可能学会Pasacl语言的语法（如果你已经掌握一个类似的编程语言），但你无法学会如何合理运用这些语法。 三天 不幸的是三天根本不够；下面的章节会告诉你为什么 十年学会程序设计 研究者 Hayes, Bloom 的研究表明，在几乎所有的各种领域，大约要十年才能培养出专业技能。 再看另一种类型的领域。 以下是我在编程上成功的秘诀: 对编程产生感兴趣并因为乐趣而写程序。 谈 了上面所有的想法后，我不禁要问究竟能从书上学到多少。 Fred Brooks (译注: <人月神话>作者) 在他的文章 没有银弹 中指出，发掘卓越软体设计者的三部曲： １．尽早尽可能地以系统化的方式发掘最佳设计人员。
这里假定了某些人已具备成为卓越设计师的必要潜能；工作只是诱导他们前进。 所以，尽管买那些 Java 书吧！ 参考文献: Bloom, Benjamin (ed.) Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no. 4, 1987, p. 10-19. Hayes, John R., Complete Problem Solver Lawrence Erlbaum, 1989. 解答: 附录 I: 语言的选择 朋友在用的. 附录II: 书和其他资源: