Hacker News Reader

Comment by andrewfromx | Hacker News Reader

when it's coding as fast as humanly possible, the last thing I want to do is slow down to think of good var names. I'll often just name something "foo" if I can't think of a good name and come back and rename it later. Sometimes it's a little better than foo but still not perfect but I'll leave that and move on to something else. I really don't like the idea that code must be perfect. Code is never perfect.

View on HN

This is another example of how everything depends on the user. From this comment I can only assume that you code by/for yourself or with very few other people, with which you surely share a lot of time and space which makes communication in that kind of shorthand possible.

And now, I want to highlight how difficult was for me to be an understanding and constructive member of society right now, and try to explain why you may be right in some cases, instead of why you're wrong in some other possibly larger number of cases, while foaming at the mouth with an eye twitching, which is what my first internet instinct was.

Even if you're working on a project by yourself this is still terrible practice! I know when I've done this and had to come back to my code weeks later, I've absolutely loathed my past self for writing opaque code.

You shouldn't be "coding as fast as humanly possible", that's how you end up with bad, brittle code full of technical debt that will be a nightmare to maintain.

Nothing's ever perfect. But code can anywhere in a spectrum from good to bad, and we should always strive to reach the good side.

Exactly. Good variable names are one of the best "bang for your buck" optimizations available. There might be other things you can do to make your code better, but few so easy and impactful.

Well, grasshopper, I guess you can code like a kung fu novice, trying to split a stone; repeatedly and thoughtlessly bashing your hands on it, making a bloody mess. Or like a master; contemplating the best way a while and then splitting the stone whith one precise, decisive motion.

Oh gosh. I really hope I will never have to work with you or ever use a product you have worked on. This is just terrible software engineering practice. You are doubling the amount of work you have to do and are creating a breeding ground for bugs. Remember this age-old wisdom "measure twice, cut once"? You are doing the exact opposite.

Great news for you, you are the master of your own destiny and never have to (:

The age-old wisdom holds of course for so many cases, but writing code isn't always software engineering. Wouldn't you grant that it would be a mistake to instil the value that all code written must be carefully crafted? There'd be a ton of missed opportunities for creativity if the act of coding was so sacred.

But what happens if you die and someone else has to pick up where you left off?

someone else is going to cry because the coder is dead and the code is unreadable

Well, at least someone will be happy at the wake.

The world will stop turning and it will all have to be rewritten from scratch.

The typical response of a developer inheriting legacy code from a no-longer-employed-there developer is "this is garbage, I need to rewrite it". So in that sense not only is 'foo' efficient for the original commenter, it is _also_ efficient for his/her replacement since it will present a very clear business case for a rewrite.

I remember working with one developer who would get in at 10:30 AM, think about ONE variable name in ONE method until lunch, take a 2 hour lunch break, and THEN maybe code one perfect method. Sorry not sorry there is a happy medium here. My code is not unreadable. I like to name something "curIndex" and move on with my life.

If you're doing fast prototyping or hacking for fun then mindless variable names make sense, but working on a production codebase that is or will likely be shared by others is a different situation.

There no argument for absolute quality in code, only value relative to its use case and context. Outside of correctness of behaviour and acceptable performance, the human-readability of code probably carries the most value in most situations.

Sure you can get by without it, but code that is readable will ultimately be more valued/reviewed/supported/improved.

Reply on news.ycombinator.com