I personally detest people who do this, outside of things like tables (i.e. structured constant initializers) and comments on type definitions. If there's a high degree of regularity in the source that you're trying to expose, there's probably a better way of doing it - extracting out common variables, using a table lookup, adopting acronym conventions for regular parts along any given axis which have the same length, so that the code naturally lines up without ugly random rivers of space down the middle.

Unsigned types, on the other hand, are just evil. Way too many people use an unsigned type because they think it represents an invariant that this value will never be negative, that it has some kind of documentation or safety aspect, but that's just wrong. Unsigned types don't act according to the intuitions of most average programmers, and things as simple as for-loops are incredibly easy to get wrong with them (e.g. think about the most common idiom for iterating backwards in C derivatives). If I had my druthers, mixing signed and unsigned ought to expand the expression to the next larger signed type that can represent the range of both (and error out if there is none), and there ought to be separate subtraction / decrement operators specifically for unsigned types. 'u += -2' where u is unsigned would be a type error - assigning a signed value to an unsigned location.