Comment by hrbf | Hacker News Reader

Comment by hrbf | Hacker News Reader

Parent Full thread

This is an argument I’ve heard over and over again throughout my coding career, especially from JavaScript and PHP developers. Interestingly enough there was a noticable overlap between this mindset and “clever” code, comprised of endless chaining, nested statements and/or internal recursion. They also never wrote code comments – at all. The defense being: “I think this way and its easier for me!” Regarding comments: “The code IS the documentation!”

Of course, they were never around 6 months later to prove if they still understood their gobbledygook then. They never had to refactor anything.

I have very rarely encountered a piece of code that would be hard to fit into 80 characters width while being readable. In fact, if done correctly, it forces you to break stuff up into manageable pieces and simple statements, to be explicit and often verbose.

But if this runs counter to a messy, ego-centric style a developer is used to and there’s no one to reign them in, it’s what you get.

This. So much.

I can empathise - when I started out I was all about clever code. But the older I get, and the more code I have to deal with, the more I value simplicity.

The 80 character limit is a really good signal that my code is too complex and needs simplifying. The most common occurrence these days is when I have too many arguments to a function, and either need to curry it or create an options data struct. My code is cleaner for this.

And there have been many, many, times that a comment from past me to 3-months-later me has saved me an hour of reading. Code, even intentionally simple code, is not as self-documenting as it appears to be when we're writing it.

Indeed. Comments should document intent and – wherever applicable – approaches taken that did NOT work and why. Even awkward code is sometimes okay, if there’s a comment with a clear justification. Saves hours of pointless busywork following down all the paths in a medium to large code base.

I used to be clever, and bumped up against the 80 character limit. Now it's the opposite: my avoidance of cleverness is what is causing me to bump up against the 80 character limit.

There are two reasons for lines to get long: (1) cleverness, or (2) long names.

I used to hate long names, and still can't stomach most Java code. But I've learned that if you want understandable code, you can either have short names and long comments, or long names and hardly any comments. (But please, no longer than is necessary to communicate what needs to be communicated. addKeyAndValueToTable() tells you nothing of use over add() or put(). setForwardingPointerWhileTenuring() does communicate some important things that set() or setPtr() would not.)

yeh, another signal that you're over-complicating things.

I stick to VerbNoun function naming, and usually code in Go where short (1-letter short) variable names are idiomatic.

If I can't VerbNoun a function, then I probably need to rethink it.

Part of the reason I don't do anonymous/lambda functions too happily - it's actually harder to read a stack of anonymous functions than a stack of VerbNoun named functions.

That's a bizarre statement, because chaining leads to shorter lines because each call can gets its own line and there are fewer assignments.

In many (most?) languages chaining leads to longer lines unless programmer makes an extra effor to break them. Compare:

     user = manager.getUser()
     mobile = user.getPhone(PhoneType.mobile)
     area = mobile.getAreaCode()

vs

     area = manager.getUser().getPhone(PhoneType.mobile).getAreaCode()

Good example and exactly what I meant. Having each call on its own line doesn’t solve anything if you also nest the calls.

what about...

    area = manager
           .getUser()
           .getPhone(PhoneType.mobile)
           .getAreaCode();

I see this form a lot in Java and Kotlin code, especially in Kotlin where a single function is just assigned to a chain of functions like the one above.

I have spent much of my career reading and understanding code written by others. Comments have helped me twice in that time.

Many other times the comments have made understanding the code harder.

My motto is that comments are the only part of the code you can be sure are not tested. At best they record the intent of an author at some unknown point in the past.

> At best they record the intent of an author at some unknown point in the past.

This probably says something about the priority the teams you worked with put on documentation. Write once and never update?

I mean the unknown point in the past could be yesterday, but it could also be 25 years ago.

Reply on news.ycombinator.com