Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Good code is like a love letter to the next developer who will maintain it

addyosmani.com

Post reply on HN
Print view View original

141–150 of 274 posts

Re: Good code is like a love letter to the next developer who will maintain it

#141

Post by 000ooo000 »

raincole wrote: post #87
imoverclocked wrote: post #57

As someone who has gone back and read my old code as well as a lot of others old code, there is no such thing as good code. IMHO, the problem is one of cultural context which is often not shared between generations of coders. Languages and best practices can change so violently that best-practices one decade are often anti-patterns in the next. As a codebase outlives its best-practices, do you stick with them and ext…

> there is no such thing as good code But do you think there is bad code? If so, I'll give you the official definition of good code: code that isn't bad code.

Suits me. Us programmers being such a negative bunch, surely we can easily build a checklist of bad code attributes and then just call any code with few ticks on the list "good code". Does it need to be much more complicated than that?

Re: Good code is like a love letter to the next developer who will maintain it

#142

Post by lcnPylGDnU4H9OF »

IggleSniggle wrote: post #139
lcnPylGDnU4H9OF wrote: post #118

Earlier quoted context omitted.

Despite this, mathematical proofs still use a bunch of plain words to define things. In a programming context, if one has an “user” from the database, “user” is usually a better name than “u”.

It really is a context and frequency thing. For example: users.map(u => u.lastName) Nobody is going to have any questions about what 'u' is here. Do that in a codebase that has a 100% consistent and very frequently used User type, and it starts to feel quite reasonable to just use 'u'. It's as familiar as Apple π.

This is a perfect example of why I think it’s “usually” better. Still, the word “user” is there in this case. It could be a lot worse:

  us.map(u => u.lastName);
Maybe that’s too close to the word “us”, meaning you and I. We can do better:

  u_s.map(u => u.lastName);
But then is that an abbreviation of something with the initials “U” and “S”? We can do better:

  users.map(u => u.lastName);
Point being that including the word on the line is what provides the clarity.

----

And a bonus option for the truly maniacal:

  you_guys.map(your => your.lastName);

Re: Good code is like a love letter to the next developer who will maintain it

#143

Post by gavinhoward »

mattgreenrocks wrote: post #122

After almost 20 years of writing the best code I can muster as much as I can, I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. Many won’t even notice; they’re too preoccupied with their own lives to open their eyes to what is there. Nor do they give a damn about mastery. But, that doesn’t mean it’s a waste. I don’t think I’d do much differently in retrospect, except…

> I’ve come to understand that most people won’t ever really appreciate it for the effort you put in.

I've had several people comment on the quality of my code. For a FOSS project. Of a command-line tool that nobody cares about.

People notice.

But yeah, this article is too much fluff because people don't see it that way.

Half of the people who commented on my code mentioned the snarky comments I wrote.

Re: Good code is like a love letter to the next developer who will maintain it

#144

Post by m00x »

dlisboa wrote: post #98
m00x wrote: post #62

Earlier quoted context omitted.

The craft is not the code, but the product. You can have beautiful code and garbage product, and great code and a garbage product. If your PM is pushing bad products, that's on them. Your job is to deliver good product, not good code.

That’s not a great way to look at it. You can be passionate about the craft and not passionate about the product. You can usually find interesting problems relating to craftsmanship even when doing things you’re not thrilled to do. Let’s be honest: sometimes you’re not “changing the world” like many founders like to think, just building yet another shopping cart. If you lose love for your craft there’s no product tha…

But you're trying to build a damn good shopping cart, which is the product.

The code analogy here would be nerding out on how to use a hammer in spectacular ways, but not really do anything interesting with it.

You can still really love your tools, but you shouldn't focus on them as much as what you're building with them.

Re: Good code is like a love letter to the next developer who will maintain it

#145

Post by m00x »

majikandy wrote: post #73
m00x wrote: post #62

Earlier quoted context omitted.

The craft is not the code, but the product. You can have beautiful code and garbage product, and great code and a garbage product. If your PM is pushing bad products, that's on them. Your job is to deliver good product, not good code.

Can’t it be both?

It absolutely can!

I'm not saying that you should disregard your code, just that it's not what you should put at the top of your list.

You can build amazing products with amazing code, and they will often raise each other up.

A great example is Redis, that codebase taught me how to write C code, and I also use Redis everywhere.

Re: Good code is like a love letter to the next developer who will maintain it

#147

Post by molsongolden »

mattgreenrocks wrote: post #122

After almost 20 years of writing the best code I can muster as much as I can, I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. Many won’t even notice; they’re too preoccupied with their own lives to open their eyes to what is there. Nor do they give a damn about mastery. But, that doesn’t mean it’s a waste. I don’t think I’d do much differently in retrospect, except…

I’ve hunted down contact info and emailed a dev who’d left the company to thank them for the clean code they left behind.

I encountered their code while debugging weird behavior in a legacy feature. The code structure was immediately intuitive and comprehensible. Just the right amount of detailed but not superfluous commenting. Beautiful. It made my day so I let them know!

Re: Good code is like a love letter to the next developer who will maintain it

#148

Post by ezekiel68 »

yodsanklai wrote: post #113

Developers love to debate about these things, but everything has been said already. I've noticed that the better the developers, the less they engage about these topics.

> but everything has been said already.

It turns out this is true for well over 90% of relevant topics on the planet. Every year in the US, over 4 million people turn 18 years old and over 3 million people of various ages die. If we contract this dynamic to people who enter and leave our industry, it becomes clearer why it is not only helpful to say what has been said already, it is vital.

The above has already been said also.

Re: Good code is like a love letter to the next developer who will maintain it

#149

Post by ezekiel68 »

m00x wrote: post #63
loph wrote: post #54

Truth. Years ago a wise man told me "The compiler is not your customer. The next person who maintains this code is your customer. It might be you."

The customer is the one using your product, not the one maintaining your code.

A common reply, but misguided. A corporate coder who is not also CMO and CEO does not produce products for the end user. They produce code units which, after build, deploy, and integration, become useful building blocks in an overall solution which may (the company hopes) be a product for the end user. From this standpoint, the code they write will often be 'consumed' by other coders and by future themselves. The consumers are therefore coders.

Re: Good code is like a love letter to the next developer who will maintain it

#150

Post by syntheweave »

lcnPylGDnU4H9OF wrote: post #142
IggleSniggle wrote: post #139

Earlier quoted context omitted.

It really is a context and frequency thing. For example: users.map(u => u.lastName) Nobody is going to have any questions about what 'u' is here. Do that in a codebase that has a 100% consistent and very frequently used User type, and it starts to feel quite reasonable to just use 'u'. It's as familiar as Apple π.

This is a perfect example of why I think it’s “usually” better. Still, the word “user” is there in this case. It could be a lot worse: us.map(u => u.lastName); Maybe that’s too close to the word “us”, meaning you and I. We can do better: u_s.map(u => u.lastName); But then is that an abbreviation of something with the initials “U” and “S”? We can do better: users.map(u => u.lastName); Point being that including the wo…

I believe a programming language could actually codify rules around how long names are allowed to be based on scope.

In a local scope, aliasing to single-letters is OK, and many codebases are littered with i,j,k,b,v,x,y,z arguments and iterators. But putting that into a nested scope has produced many errors for me as I accidentally declare a new n or v and then try to access the outer one. So I'd enforce uniqueness when nesting.

After some experience with Pascal, I thought the idea of implicitly reserving "result" as the name for the returned value was a good idea, but also a bit long. Taking a page from TI-BASIC I have settled on "ans" for "answer".

Global variables generally have to be a bit longer to not collide. In my own investigations, this happens at four characters: while you can devise some two and three-character abbreviations that work at language level, at four you start getting more complete English words(and English is a bit part of this whole estimation, more densely encoded languages will have their own metrics).

Types, functions and classes often cause woes, because they need to be accessed across modules, and modules will use names in linguistically dense ways, but they should not expose that as the default interface in most cases. Here I think the goal should be to have full namespace qualification as the default, and then gradual relaxation near the callsite through explicit aliasing and redeclaration.

That last part makes me think that I can go further with what I alias in some languages. Eg. in Haxe, I have the freedom to throw in "typedef Foo = com.corporation.big.fancy.Package.Classname.Method" wherever I like.

Post reply on HN