> inequality x!=y is not used at all, because it is two chars. instead, we test with x-y, which holds true when operands differ
I think this is the line in the document that represents his coding style the most. Sacrificing legibility for plebs to save one character per comparison.
i agree that atw’s inequality test is a bit cheeky, but like everything else it is a matter of habit. a convention. eventually you just begin to see what is subtraction and what is comparison.
here’s another classic example of the same effect:
x=x+1
makes perfect sense to everyone, right?
wrong. to some, the right answer is “no, they are not”.
I am not saying it's bad. I kinda understand the motivation behind atw style in general. Modern code is written like prose:
if (IsValidFile(fileName)) {
var rawRecords = ReadFileAsRawRecordIterator(PreprocessFile(fileName), config);
foreach (var rawRecord in rawRecords) {
var record = ParseRawRecord(rawRecord, config);
//and so on
}
}
But you have to trust the prose. At one point or another, you find a bug in some free software you haven't written yourself, open its source code and are met with ravioli code written in prose. And you cannot trust this prose because there is a bug in it. So you open this tiny method, the you open PreprocessFile, ReadFileAsRawRecordIterator, ParseRawRecord, the implementation of IRawRecordIterator, then a few more methods that these methods call themselves and try to thread the control flow through these methods, jumping from file to file. I can see how atw style code can help with that, especially after you retrain yourself to read it like math.
I think this is the line in the document that represents his coding style the most. Sacrificing legibility for plebs to save one character per comparison.