sure. the reason i put a line break between return type and function name in c-likes is `grep ^fname`. but i seriously wish greppability wasn't important. the extensive line-orientedness of unix tools really puts a damper on the whole hose-of-bytes concept, and it's no wonder by the time of plan 9, there was a strong desire to do away with it—cf. "structural regular expressions", as deployed in sam(1), which, of all the places to put them, certainly has historical irony, as sam's (decidedly not line-oriented) editing language nonetheless descends from ed, the definitive line editor, and gave us such hits as "stream ed" and "simulate typing `g/regex/p` into ed".

just the other week i noticed a change in recommended formatting style in a project i contribute to regularly, and the result was source files got about 20% taller, 20% more of a pain in the ass to edit without some sort of syntax folding. the rationale? diff. making you reach for a syntax-aware editor to compensate for a deficiency in the syntax-awareness of a version control frontend is certainly a choice.

the business end of git as seen by most programmers is in fact diff city, sure, but deep down git is a bunch of snapshots. even deltas behave nothing like diffs. pull up the spec for the pack format and look for the word "line". you will not find it.

things could be so much better, but for now we live in a world where the headline is true.