Mercurial merging tip

This trick helps doing a lot of merges in a commandline

hg merge `hgrev dev`

where hgrev is a bash function for finding the changeset hash:

hgrev() { local headname=$1; local rev=`hg head $headname | head -n 1 | gawk '{split($2,a,":"); print a[2]}'`; echo $rev }

write a readable code

Readability is a king. In a language, which major success happened mostly due to its improvements in readability, it is all about profound and aesthetic forms. Have you thought about it that way - the code as we read it is not the same code as we write it. Indeed, the "encoding" and "decoding" paradigm is a constantly reversed process during the software development. But what I personally find the most irritating is an expression "to write code" or simply "to code", which is irresponsibly attributed to the program composing activity. It is not only the semantics that suffers, but the very creative soul of the intellectual act.

Coding is all about translating a language of the concept into a language of the program. But in practice, not code, but stenographic writing is what is so often produced as an output. A perfect programming solution is already a language itself. An average developer is first lured by promising advantages of certain language, then steadily and dogmatically converted by its "exciting" lovelinesses, finally starts desperately advocating for something which he does not really masters or senses. All this painful evolution is normally cycled, when our newly matured adept continues the bloody expansion by converting new casualties. But the trick with any formal language is that it is not more than a handy instrument to put a group of symbols in a grammatically arranged joint. All the work, left there untouched, is to be conducted by the author of the program. It is the author who declares variables and drives the semantical wheel of specifying the identificators. It is he who governs the distribution of complexity through vast functionality. It is he who makes things come alive by telling the story behind the algorithm.

So, the real question is how definitive a good program could be? The code which is self-explanatory is a masterpiece of an inter-human communication (omitting the presence of computer as a mere necessity), thus automatically must be graded as a program. Such code does not require any artificial documentation or redundant comments. Such code is a pure logical semantics - above any formalism or hyper-consistency.

The introduction of the post was indeed a dramatical overkill. A reasonable need for an example must bring the discussion to a firm ground.

Python is one of those languages that, although intended to grasp the impossible - propose a constitution for perfect formalization - and, IMHO, failed, nonetheless has done better than most of its competitors. It is always up to python developer to resolve the design dogma "there is one and only one way to do something".

The following equivalent statements are a good example based on os module usage for some strings (a, b, c):

assert(os.path.join('a', 'b', 'c') ==  os.sep.join(('a', 'b', 'c')))

Mastering the ability to conclude which construction maybe preferable to the code readability can turn out to be an important asset in producing consistent code.

Another important example is:

a = ''
assert(len(a) <= 0 == not a)

Implicit casting of a string or a list variables of zero length to boolean False, may turn out to be priceless in producing shorter, but more readable forms.

There are even more examples. Most of them must be known from studying PEP8 (Programming Recommendations). Others are an important piece of valuable practical knowledge, collected with time.