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).
Plan 9 regular expression library. 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. In no way, do I disparage that approach, instead I think that there is room for another list that is more technical in nature, but the question remains, where to go next? 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) 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.高效能编程的七个好习惯.
这七条都是我这个不怎么高效能编程的人悟到的.
不权威, 不一定全对. 1. » 十年学会程序设计. Peter Norvig (Copyright 2001) 原文网址 为何大家如此匆忙?
走进任何一家书店，你会看到书架上一排不见尽头的放着如 <7天自学Java语言> 以及几天或者几小时学会Windows, 因特网或者Visual Basic 这类书。 我在Amazon 网上书店用一下的方式进行高级搜索: 出版年份: 1992以后 书名包括：“天” 和 “学习” 或 “自学” 得到了268条搜索结果，其中前78条都是计算机书（第79条是 30天学会孟加拉语）。 由此可见，人们要不就是急着想学会计算机，要不就是计算机相比于其他事情太容易学会了。 让我们分析一下 三天学会Pascal语言 [英文网页] 这样的标题表达了什么意思： 学会: 在 三天内，你没有时间去写几个有意义的程序，或者从成功和失败中学到东西。 Pascal 语言: 三 天内你可能学会Pasacl语言的语法（如果你已经掌握一个类似的编程语言），但你无法学会如何合理运用这些语法。 三天 不幸的是三天根本不够；下面的章节会告诉你为什么 十年学会程序设计 研究者 Hayes, Bloom 的研究表明，在几乎所有的各种领域，大约要十年才能培养出专业技能。 再看另一种类型的领域。 以下是我在编程上成功的秘诀: