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

101–110 of 274 posts

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

#101

Post by another-dave »

BugsJustFindMe wrote: post #31
Arisaka1 wrote: post #16

Earlier quoted context omitted.

Yep. Yesterday I ran into a job opening asking for "Java developer who delivers 3x faster than the other developers" in one of the bullet points. It's such a weird point to emphasize that you want speed with no concern to trade-offs, and the maintainability and scalability of the codebase will be the first victims sooner or later.

My personal experience is that the majority of developers I ever encounter at work (as opposed to within my social network) are usually slow because they're bad engineers who don't understand problems quickly, don't have the knowledge or experience to see solutions quickly, and in general don't think deeply quickly. It's not hard to 3x performance without sacrifices when the baseline is mediocre at best. "Fast must b…

While this is true, if a job ad is telling me that that's _their_ experience of their average hire, it's probably not somewhere I want to work!

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

#102

Post by Alupis »

jiggawatts wrote: post #90
38 wrote: post #70

Earlier quoted context omitted.

> there is no such thing as good code definitely not true. this is good code: https://github.com/torvalds/linux/blob/master/fs/file.c this is good code: https://github.com/golang/go/blob/master/src/strconv/atoc.go its formatted, commented, direct. the fact that you struggle with writing time tested code does not mean that everyone does.

By linking to those examples you confirmed the point you were trying to refute. From my personal perspective this is mediocre code at best. It’s written in an unsafe language. Littered with macros, which in C are not hygienic and are land mines in waiting. Constants defined with lowercase and not actually marked as const. Double underscores everywhere, which are the bad alternative to namespaces seen in weak language…

The issue so very many people fall into is assuming some foreign-looking codebase is awful.

What people typically mean to say is something along the lines of "I haven't a clue what this does, haven't enough experience with the language to understand it, or how people use it".

Go look at code written in "safe" languages like Rust and tell me you understand what it's doing any better than well written C code.

You have to know the language to understand what is sane or not, what the conventions are, what the common issues are, etc.

Same with all the Functional stuff out there. To a OO person, it looks bat poo insane. But if you learn FP, it's natural.

Some of your complaints are valid from the perspective of someone who doesn't do kernel work. For the people who do work on the kernel, the macros, abbreviations, etc are common place and well understood, and a complete non-issue.

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

#104

Post by voxelghost »

38 wrote: post #70
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 definitely not true. this is good code: https://github.com/torvalds/linux/blob/master/fs/file.c this is good code: https://github.com/golang/go/blob/master/src/strconv/atoc.go its formatted, commented, direct. the fact that you struggle with writing time tested code does not mean that everyone does.

Reminds me of this good old rant from Peter Welch, Programming Sucks

    ...

    Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.

    This file is Good Code. It has sensible and consistent names for functions and variables. It’s concise. It doesn’t do anything obviously stupid. It has never had to live in the wild, or answer to a sales team. It does exactly one, mundane, specific thing, and it does it well. It was written by a single person, and never touched by another. It reads like poetry written by someone over thirty.

    ...
[ https://www.stilldrinking.org/programming-sucks ]

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

#105

Post by bcoughlan »

renox wrote: post #69

The emphasis on tests made me laugh: I work on a project where it's mandated that all the code is covered by Unit Tests. In my estimate the time to make UT is 3* the time to create the code. And no, nobody use TDD in this project because it takes 3 minutes to compile one UT (C++ sigh), so we all do 'post coding' tests. While sometimes the UTs do help, they're also a huge burden: wants to fix some code? Well you also…

Overly granular tests are a scourge of our industry, unless you’re writing a widely used utility library. It leads to tests that become a useless burden for even mild refactoring.

Writing larger test cases that test the actual functionality is a game changer. With Testcontainers and good mocking tools you can spin up a real version of your app with external dependencies mocked and faked, and write test cases against the same input layer your user uses. If your test fails you can be pretty sure it’s because you broke something.

This is a layer between unit and integration tests that you don’t read much about. I call them “service tests” (coming from a microservices world).

Investment is still needed though to reduce the effort of implementing tests, like extracting common fixture code so that every test doesn’t need long winded setup code. Also snapshot testing libraries take the pain out of writing assertions.

I am speaking from the API based backend world so YMMV. Once you’ve worked this way it’s hard to go back. Any developer can come in and confidently make changes. You spend way less time investigating regressions and broken environments, so you can release more frequently (which takes a whole other layer of pressure off the team)

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

#106

Post by sudosysgen »

cookiengineer wrote: post #92
jiggawatts wrote: post #90

Earlier quoted context omitted.

By linking to those examples you confirmed the point you were trying to refute. From my personal perspective this is mediocre code at best. It’s written in an unsafe language. Littered with macros, which in C are not hygienic and are land mines in waiting. Constants defined with lowercase and not actually marked as const. Double underscores everywhere, which are the bad alternative to namespaces seen in weak language…

I think I just fell in love with you. Finally a sane person Honestly, I never understood why so many developers abbreviate function names or variables. Is it so much pain to type abc for auto completion? Why not simply name fd file_descriptor? Short names are a mental barrier and a level of abstraction that can easily be avoided.

In some languages, that leads to terribly long lines that you then have to break down, add indentation, and it just becomes harder to read. There is happy middle.

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

#107

Post by nemetroid »

cookiengineer wrote: post #92
jiggawatts wrote: post #90

Earlier quoted context omitted.

By linking to those examples you confirmed the point you were trying to refute. From my personal perspective this is mediocre code at best. It’s written in an unsafe language. Littered with macros, which in C are not hygienic and are land mines in waiting. Constants defined with lowercase and not actually marked as const. Double underscores everywhere, which are the bad alternative to namespaces seen in weak language…

I think I just fell in love with you. Finally a sane person Honestly, I never understood why so many developers abbreviate function names or variables. Is it so much pain to type abc for auto completion? Why not simply name fd file_descriptor? Short names are a mental barrier and a level of abstraction that can easily be avoided.

Anyone who has reason to read this file will have "fd" as a word in their vocabulary.

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

#108

Post by imoverclocked »

NetOpWibby wrote: post #2

Precisely why I also create READMEs in top-level directories. I'm not going to remember how to structure queries for my API a year from now. Future me will always appreciate how considerate present me was.

> Future me

I like this term a lot more than "the next developer."

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

#109

Post by buzer »

cookiengineer wrote: post #92
jiggawatts wrote: post #90

Earlier quoted context omitted.

By linking to those examples you confirmed the point you were trying to refute. From my personal perspective this is mediocre code at best. It’s written in an unsafe language. Littered with macros, which in C are not hygienic and are land mines in waiting. Constants defined with lowercase and not actually marked as const. Double underscores everywhere, which are the bad alternative to namespaces seen in weak language…

I think I just fell in love with you. Finally a sane person Honestly, I never understood why so many developers abbreviate function names or variables. Is it so much pain to type abc for auto completion? Why not simply name fd file_descriptor? Short names are a mental barrier and a level of abstraction that can easily be avoided.

Short names actually help with readability when they are commonly used. It's a lot quicker to go over the code when you don't need to read as much, similar to how one would write something like x+y=z in math instead of putting descriptive name for each variable in each step or using things "1€/kg" instead of "one euro per kilogram" (or let alone including kilogram's definition from SI standard).
Post reply on HN