Hacker News Reader

Comment by ppeetteerr | Hacker News Reader

Any time I read C/C++ code, I am under the impression it was written to be illegible.

I realize that with time, functions like `malloc` become second nature, but why not call it `allocate_memory`? (bash suffers from this too) It's even worse when reading the source code of old video games due to the abstract nature of the operations being performed on virtual representations of visual elements.

The argument of time constraints when authoring doesn't hold much value. Java is verbose AF but it's also one of the most used languages. Second, most code is read, not written and should be written to be read by others, not just the author.

There may be a reason to be terse due to time constraints and lack of IDEs/autocomplete or memory constraints or w/e, but the need to shorten variables names and functions today only serves the whims of the author, not the 10+ future readers. tinyrant :D

View on HN

For the standard library and such that train has left the station... way too much legacy code and learned knowledge.

As to why it happened in the first place: it is from an era when some compilers only looked at the first 8 characters for uniqueness of a name. Toss on top of that that a screen was only 80 characters wide and short names made a lot sense.

Now it is just tradition, I feel, more than anything else.

> Toss on top of that that a screen was only 80 characters wide

There are still developers that insist on code only ever being 80 characters wide, even in today's world of 24+ inch, 1920x1080+ monitors.

I understand wanting code to be narrow enough to be able to have diffs side-by-side, but you can get 120-character wide lines and still achieve that.

I've seen others argue that if a line is too long, it's harder to understand what it's doing, and I would agree with that with one caveat: In this context, "line length" should be understood as the number of operations being done, not necessarily absolute number of characters. A line that is 110 characters long but has meaningful variable and function names is going to be easier to grok than a line with only 60 characters but has terse names.

I'm one of those dinosaurs who prefer 80 character limit, thank you. I have a 24-inch monitor, and I like seeing three different files, a terminal output, and a stackoverflow page on Chrome, preferably at the same time.

Regarding variable names, it's a matter of taste, but for example:

    NumberOfDocumentsProcessed += MaybeFindUpdatedDocuments(ClientPool->GetClient(NextClientIndex++));
    n_docs += find_updated_docs(cli_pool->get(next_cli_idx++));

I find the second line much more pleasant to read, especially if these variable names repeat several times in a function, which they usually do. The problem with long lines is that the style inevitably drifts toward the first example, because nobody can say no to "Can we make the names more descriptive?" With 80-character limit there's a certain friction that acts as a counterbalance.

> There are still developers that insist on code only ever being 80 characters wide, even in today's world of 24+ inch, 1920x1080+ monitors.

Resolution is largely irrelevant. The size of the font and screen size/distance is what matters for readability.

Think in terms of books that are pleasent to read. If the lines are too long it’s easy for some to lose track of where they are. If the font is too small people with poor eyesight will have trouble reading anything. Character limit is an accessibility issue. I am personally limited to ~80 characters for my use case.

Though the issue is largely irrelevant for people who are know of therecent AST aware formatting tools that can limit lines to whatever length you’d like.

There was a time where visual and actual compactness was important. So for instance things like `malloc` date to that era. I'd argue that changing it to `allocate_memory` now would be even more confusing than leaving it as `malloc`

I fully agree. This reminds me of how some text books will teach people to write `a = 10` rather than `age = 10` for the sake of brevity. From that moment on, it becomes a habit to write code in a terse manner. It took me a few years and some good IDEs to no longer be afraid of names like `ageOfUser`/`age_of_user`.

Hopefully not modern textbooks.

I know when I was in my CS program in the early 90s it seemed like that was transitioning. The older profs would teach us every trick in the book to reduce the actual file size & visual noise in our code. The younger profs would beat in our head to not do that.

Even in modern languages with traditions of verbosity, the moment they add generics they almost always go back to single letter names.

Map<K,V> drives me nuts. Especially since K has to be comparable and/or hashable.

> `ageOfUser`/`age_of_user`.

I'd be going with `userAge` or `user_age` either way. :-P

We can't be friends :P

> There was a time where visual and actual compactness was important.

It still is; there is a reason people tended to shorten terms in the field they are deeply engaged in. Verbosity gets in the way, and there is always a tension with it (and where the optimum point for clarity is depends on the focus and expertise of the audience.)

I believe I also read that the keyboards they used in the 70s stank so bad that they wanted to avoid typing long stuff out.

There were a lot of reasons for concise, pithy code in the 1970s. Poor keyboards was not one of them.

(in fact, some of the best keyboards I've ever used were of the old mechanical-switch variety found on IBMs, teletypes, and various CRT terminals. Even the worst of the bunch were a lot better than the almost-legendarily-bad macbook keyboard I'm using at this moment.)

http://www.catonmat.net/blog/why-unix-commands-are-short/

> I was watching videos about my favorite topic, UNIX history, and found a talk by Hendrik Jan Thomassen. He's the UNIX pioneer in the Netherlands and has worked with Thompson and Ritchie in the past. He says the real reason why UNIX commands like ls, cp, mv, etc., are short is because PDP11 console keys were super hard to press. You'd get knuckle pain if you typed too much. So to save your fingers, all the commands were designed to be as short as possible. True or not, that's a fun story.

The page includes a video.

That's a great contribution. Thank you! And all this time I thought they were mere stylistic choices.

As an undergraduate, I was relegated to the teletypes or a modem on one of the 10 dialup lines -- upperclassmen and grad students got first pick of the CRTs and there was rarely a free one available. I suppose I get the last laugh, as I didn't developer carpal tunnel syndrome.

Coding assembly on a teleterminal using greenbar paper now seems equal parts primitive, badass, and insane.

Java is so verbose it induces semantic saturation which makes t harder to read

I mean, it's the same thing. If you're used to reading it you know what parts are relevant to what you're doing and what parts aren't. The difference is that if you don't know the language at all and look at some code you can likely understand what it does.

I agree that Java makes reading hard with regard to the semantics and unnecessary data structures for simple things like anonymous functions. I would point to Python, which is semantically the easiest language to learn. It's still possible to write illegible code (primarily due to the lack of indicator of argument and returns types and, of course, bizarre variable names).

I highly recommend the type annotations along with mypy for helping code readability in Python

Reply on news.ycombinator.com