Good code is rarely read • Hacker News Board

Re: Good code is rarely read

#111

Post by madsbuch » Sun, Jun 16, 2024, 2:28 PM UTC

m463 wrote: post #100

madsbuch wrote: post #6

Earlier quoted context omitted.

Exactly my thoughts. The reason why good code is code that is easy to read, is because products evolve, and so does the code. Suddenly the taxonomy of that enum starts to shift, and the name that was perfect yesterday does not make sense tomorrow. These changes happen gradually and a basic acceptance of the code base not being on par with the product understanding is necessary in order to have any kind of velocity on…

I disagree. "good code is easy to read" - that does not work. I can write a bubble sort instead of quicksort and that code will be bad. Maybe you can do the same thing with privacy policies. Most complicated privacy policies are bad, so they make them hard to read so that people do NOT understand them and give up. But you could have a privacy policy that is bad and easy to read. "We can do anything". I think good cod…

Of course your code should live up to requirements and be correct, for it to be good - The requirements can also be performance requirements.

If you have a list of maximally 10 elements that needs to be sorted and you opt for quicksort over bubble sort in a context where bubble sorts time/space guarantees perfectly solved the requirements, well, then you absolutely wrote bad code.

This is what a more senior developer understands, where a junior would jump in and write worse code.

Re: Good code is rarely read

#112

Post by weebull » Sun, Jun 16, 2024, 3:28 PM UTC

davydm wrote: post #2

I don't think the author has worked on long-lived projects. Eventually, all code is revisited because there's always shit to get done.

There's a class of code where you never need to read it because it's effect is well understood and it does it without problems. It has the right level of abstraction to be useful in multiple places and not specific to a singular case. It's not going to be top level code, but it's a building block you know you can rely on.

This is something I think functional styles of programming lead more naturally towards than OO or procedural. It's far easier to separate concerns when you can pass around like bundles of functionality (i e. first order functions). Also it really helps when you are used to writing code with no dependency except what is passed in, and not effect except what is returned. Then thhen you're sure that the code is not leaky in it's abstraction.

You can do it in other paradigms, but it's it's not where the language naturally leads you. OO has retained state as a key foundation of it's philosophy. Procedural code tends to mix up the how something is done and the what is being done. (e.g. the iteration through a data structure, with the definition of what is being searched for).

Re: Good code is rarely read

#113

Post by mewpmewp2 » Sun, Jun 16, 2024, 5:05 PM UTC

tanseydavid wrote: post #92

x0x0 wrote: post #59

Earlier quoted context omitted.

> Adding features to a code means it was incomplete. That definitely implies code can't be good if needs change, which makes no sense to me.

Missing feature implies an error at the Requirements level. This does not impact readability or the idea of "good code" in my opinion. You could have an application that is missing features which still contains examples of "good code". Learning about "good code" by reading the source code of this application won't really give any direct hints of missing features...the granularity is different.

What about changing features? E.g. a feature has to change 2 years down the line because certain laws are passed and this changes how the business logic should behave.

Re: Good code is rarely read

#114

Post by mewpmewp2 » Sun, Jun 16, 2024, 5:07 PM UTC

x0x0 wrote: post #70

CuriousCosmic wrote: post #63

Earlier quoted context omitted.

Adding features means it was incomplete. Good code can essentially always be built upon instead of modified.

But code can be complete and then become so-called incomplete because, again, needs change. eg someone releases a new file format. You believe ffmpeg is bad code?

In that case you could argue that you would be just writing new code to write a handle for that file format.

In ffmpeg case I assume this is how it would be.

Re: Good code is rarely read

#115

Post by [deleted] » Sun, Jun 16, 2024, 5:16 PM UTC

weebull wrote: post #112

davydm wrote: post #2

I don't think the author has worked on long-lived projects. Eventually, all code is revisited because there's always shit to get done.

There's a class of code where you never need to read it because it's effect is well understood and it does it without problems. It has the right level of abstraction to be useful in multiple places and not specific to a singular case. It's not going to be top level code, but it's a building block you know you can rely on. This is something I think functional styles of programming lead more naturally towards than OO o…

[deleted]