> Make all of your leaf classes final. After all, you're done with the project - certainly no one else could possibly improve on your work by extending your classes.
It's actually a good advice. A class not designed to be extendable should be marked as final.
Especially since it takes like 2 seconds to make said classes unfinal and there are no negative consequences of doing this.
But 1999, that was peak "inheritance is how we fix everything" thinking.
About the only reason to not do this is if you are writing a library. Even then, it's better to make extensions available through things like closures (not really available in 1999).
In fact, I'd go so far as to say that classes not being final or sealed (C#) by default is another failure to set sensible defaults, akin to "everything is mutable unless explicitly marked const".
Properly designing classes for inheritance takes proactive care and is, in my experience, almost never done unless the author has been forced to by external forces (through APIs or agreements with other developers).
>4. Use acronyms to keep the code terse. Real men never define acronyms; they understand them genetically.
I'll see this and raise inherited SAS code where data sets in the process were named "AAA", "BBB", and so on. To prevent any kind of naming reason, even chronological, new data sets could adopt others' when the existing data set would no longer show up in the program. Which was so helpful when updates needed the previous data.
Back in 1997 I was assigned to convert a legacy SAS 5 application to SAS 6.
Let's just say that the original programmer had adopted MANY of the techniques in the linked post. The first thing I did was to go through all the code and convert it to only have one statement per line. eye roll
I feel this in my bones. I had to wait for them to invent LLM agents that could reverse engineer an application to a specification before I could stat to unravel code I inherited.
> Make all of your leaf classes final. After all, you're done with the project - certainly no one else could possibly improve on your work by extending your classes.
It's actually a good advice. A class not designed to be extendable should be marked as final.
Especially since it takes like 2 seconds to make said classes unfinal and there are no negative consequences of doing this.
But 1999, that was peak "inheritance is how we fix everything" thinking.
About the only reason to not do this is if you are writing a library. Even then, it's better to make extensions available through things like closures (not really available in 1999).
In fact, I'd go so far as to say that classes not being final or sealed (C#) by default is another failure to set sensible defaults, akin to "everything is mutable unless explicitly marked const".
Properly designing classes for inheritance takes proactive care and is, in my experience, almost never done unless the author has been forced to by external forces (through APIs or agreements with other developers).
>4. Use acronyms to keep the code terse. Real men never define acronyms; they understand them genetically.
I'll see this and raise inherited SAS code where data sets in the process were named "AAA", "BBB", and so on. To prevent any kind of naming reason, even chronological, new data sets could adopt others' when the existing data set would no longer show up in the program. Which was so helpful when updates needed the previous data.
Back in 1997 I was assigned to convert a legacy SAS 5 application to SAS 6.
Let's just say that the original programmer had adopted MANY of the techniques in the linked post. The first thing I did was to go through all the code and convert it to only have one statement per line. eye roll
Original: https://www.mindprod.com/jgloss/unmain.html
Ah, time to copy this into the custom instructions for an LLM to amuse myself with.
This exists: https://github.com/TheDrunkenLordOfEverything/how-to-write-u...
Claude Skill for Java code straight from the essay
Honestly, it'd be really funny to try and make a CLAUDE.md file for slop maxxing.
Could make that an AGENT.md and use a dumber model via opencode to slop maxx even harder!
https://news.ycombinator.com/item?id=10237636
And
https://news.ycombinator.com/item?id=34121624
https://news.ycombinator.com/item?id=17781475
Thanks.
I feel this in my bones. I had to wait for them to invent LLM agents that could reverse engineer an application to a specification before I could stat to unravel code I inherited.
AKA how to assert dominance and improve your job security
One of my favorites to come back to periodically
[flagged]
[dead]