Let’s talk about SegWit. While I never was a fan of SegWit, the Hong Kong agreement seemed like a reasonable enough compromise to me to go along with it. Now that Bitcoin Core decided to betray the community by not abiding by its agreement, it is time for me to express why SegWit is not great.
Code review has become a standard programming practice, for open source projects, but also for many companies that practice it in house. While this practice has proven to be very valuable, many developers struggle with it. So here are some tips and tricks that will help you work more efficiently when code review is involved.
There are (at least) 2 persons involved in code review. Someone that I’ll call a contributor, who want a piece of code to be merged, and a reviewer, who try to confirm that this piece of code meets quality standards and won’t introduce too much complexity compared to the value it provides. Making the whole exercise efficient requires each party to understand and empathize with the other and act accordingly.
OOP is known (or should be known) as a behavioral abstraction. It nicely solves a vast variety of problems, but enforces on the programmer an abstraction that doesn’t fit every problem. The fact is, you sometime need objects as data abstractions and not behavioral abstractions.
This is commonly the case for tools that manipulate code. A parser typically returns an AST that will be processed. The processing can be compilation, code formating, code analysis, and basically any other use related to source code manipulation.
Following regular OOP principles, manipulations have to be implemented by the AST node classes. This is a problem, because it prevents any 3rd party developer tool to reuse an existing parser and AST. The known solution is to use the Visitor pattern, which allows to dispatch in our code according to the AST node’s type.
The Visitor pattern has many known problems, to the point that many consider it an antipattern. A better solution using D has to be proposed.
Duplication is probably the #1 enemy of clean code. Its presence make the code harder to maintain, harder to evolve, more bug prone, harder to test and probably eat babies every morning. If almost any developer will agree on that fact, me can also notice that almost every codebase is crippled with repetitions in the code. How could we explain that ?
I noticed that I was using a pattern of my own more and more. It is actually very usefull, for several reasons. It may have been used by other before me, but never saw a name for it.
This pattern can be used in any language that support first class function and hashtable, that is becoming more and more common (closure support was added in PHP as of version 5.3).