Long lines of code hurts readability even with modern displays--there's a reason LaTeX defaults to something like ~60 characters a line. Shorter lines are much

Long lines of code hurts readability even with modern displays--there's a reason LaTeX defaults to something like ~60 characters a line. Shorter lines are much easier on the eyes. Besides, I usually like to have a few files open side-by-side, so I don't have that much horizontal space even on a big screen. I'm not saying this in defence of cryptic shorthand but in defence of sane line lengths and margins. Also, unsigned_int is not a great name. It's too long and it doesn't make sense--if it can't be negative, it doesn't make sense to think of it as an integer by analogy! I much prefer something like Haskell's Word types: Word, Word32, Word8 and so on. Short, easy on the eyes and clear. Ultimately, really verbose names like UnsignedInteger and WriteCharacter just add noise to your line and obscure the structure of the code. While it's nice to be clear, chances are you will be seeing these words all over the place so you want them to be short and get out of your way. C goes too far in that direction with incredibly cryptic function names[1], but I think you go too far in the opposite. Similarly, I think completely eschewing symbols is a bad idea. Symbols give your code structure that plain words lack. With a mix of symbols and names, code is neatly delimited between the parts that specify "stuff" (variable and function names) with the parts that specify "structure" or "operations" (control flow, auxiliary things like variable assignments and pointers and so on). I think a good example here is bitwise operations. I think C's operators like <<, >>, &, ^ and | make for significantly more readable code than their named versions (shiftLeft, shiftRight, and, xor, or). Compare a simple snippet from Hacker's Delight: (x & y) + ((x ^ y) >> 1) (x and y) plus ((x xor y) shiftRight 1) Sure, the first version is cryptic to someone unfamiliar with bitwise manipulations, but I think it's ultimately much clearer. If you're going to be doing more than a handful of bitwise operations in the future, the notation is well worth learning. Code is read more often than it's written, but it's skimmed even more often than it's read. With a healthy mix of symbolic notation and names, I can easily get the gist of code at a glance and mentally skip around. With just words in the Python style, I have to actually read each line of code--a serious drag on going through a codebase. I really don't want to have to read code unless I really have to! Words may be clearer to the uninitiated--people without experience in the relevant language or libraries. But for common tasks, I feel this is really optimizing for the short term (learning) and against the long term (working with code). It's worth learning some special notation if it comes up often because that notation can be more succinct, convey information more efficiently and--the most important part, to me--can be easily read at a glance. I certainly don't think C has a good syntax, for several reasons including the fact that it often goes too far in trying to be concise. But at the same time, I hardly believe in the traditions of Java which embraces verbosity and uniformity at the expense of clarity and expressiveness (just take a look at BigInteger!) or Python and Ruby which try too hard to read like English and end up forcing me to read too much. [1]: Functions like: ioctl, atoi, fputc, strxfrm. Life gets even worse when you get into intrinsics! I wrote more about this in another HN post: https://news.ycombinator.com/item?id=6717209 https://news.ycombinator.com/item?id=6717209