3 ms·
Coming from C/C++ and Having worked for 5 years within the java world now, i must admit that the naming "conventions" and variable abbreviation in c code or mor
by splittingTimes 5y ago
Coming from C/C++ and Having worked for 5 years within the java world now, i must admit that the naming "conventions" and variable abbreviation in c code or more specifically Linux kernel code form a high entry barrier for me. Why is it so hard to write things out? We all look up to the various Linux philosophies (keep it simple, do one thing, etc), but to me it feels that this kind of code style is not written with a human reader in mind, but comes from the programmer perspective of "what is the shortest way and type as few characters as possible."
This kind of overhead seems so unnecessary and alienating.
- theamk 5y agoI think the name shortening is very common in practically every science - and when we are not restricted to ASCII it is even worse, you would see mostly single letter names, combined with subscripts, superscripts, fonts, extra alphabets like Greek and so on. At least things like ifr_flags are easy to read, easy to type, and unique enough you ca search for them.
- linguae 5y agoC and Unix are from the early 1970s. They date from an era that predates the prevalence of large, bitmapped displays. There is a famous photo of Dennis Ritchie and Ken Thompson at a teletype in 1972 (http://www.columbia.edu/cu/computinghistory/teletype/ken-and-den.html http://www.columbia.edu/cu/computinghistory/teletype/ken-and...). When the luxuries of modern IDEs, bitmapped displays, and high amounts of untapped computational power are unavailable, the programming environment and operating system need to adapt to the technologies that are available. The convenience of terse names is more pronounced in an environment of teletypes. On the flipslide, Smalltalk, also developed in the 1970s, has much longer names. But Smalltalk was developed for the Xerox Alto (https://en.wikipedia.org/wiki/Xerox_Alto https://en.wikipedia.org/wiki/Xerox_Alto), an expensive machine with a bitmapped display, luxurious even by 1980s standards. Lisp also gradually embraced longer names as technology improved; compare the early Lisps of the early 1960s to Common Lisp, which first appeared in the mid 1980s. C and Unix are products of their relatively spartan environments from the early 1970s, whereas Java, a product of the 1990s, was influenced by Smalltalk, which was born under less austere conditions.
- jhgb 5y ago> On the flipslide, Smalltalk, also developed in the 1970s, has much longer names. But Smalltalk was developed for the Xerox Alto (https://en.wikipedia.org/wiki/Xerox_Alto https://en.wikipedia.org/wiki/Xerox_Alto), an expensive machine with a bitmapped display, luxurious even by 1980s standards. Long selectors in Smalltalk make sense as they're split and interleaved with arguments. Even a single programmer would probably write the same code for both environments differently when it comes to naming things.
- Razengan 5y ago> are from the early 1970s But why do we still have to suffer in 2021?
- Aditya_Garg 5y agoWe’re still using QWERTY keyboards, some things are just a product of history.
- tamrix 5y agoThey literally had size limits on variable names back then.
- hermitdev 5y agoNot just variables. When I was doing 68k assembly, even around year 2000, the assembler had a limit of 8 bytes for all labels. So, functions, branches, jumps, etc all limited to 8 byte labels. I was in college at the time and any sort of external linker or anything was beyond us at the time, so it meant all of our programs were in one monolithic file. It was hard to manage and give meaningful names by hand to labels in a 40k LOC assembly file where every label had to both be unique and only the first 8 bytes mattered.
- 9dev 5y agoI feel the same way. This limitation might have made sense in times of teletype, limited variable names and small displays, but that was decades ago! We have powerful IDEs that automatically finish every identifier we write, huge, high-resolution displays and exhaustive online documentation available at all times. I don't see any reason to continue writing code like that: In the comments of every single coding style article posted on HN, people are quick to throw stuff like "code is written once, but read many times" around. Why wouldn't this apply to C or Linux kernel code?