Hacker News Reader

Comment by JCDenton2052 | Hacker News Reader

JCDenton2052

You can learn what constitutes good code by reading bad code- it is safe to assume that there is a lot more bad around than good! Some flags:

-God objects (they do everything!) and their opposites, freeloaders

-1000-line methods

-No unit tests

-Not-invented-here syndrome, otherwise known as "let's write our own array class!"

-No separation of concerns (everything mashed together)

-Not concerned with issues such as performance, maintenability and security

After you look at too much bad code (which, by the way, will include your own), you acquire a very instinctual understanding of good practices.

View on HN

"-Not-invented-here syndrome"

The counter to this is dependency hell. I oft times see developers pulling in large, new and compiled dependencies into Python projects for a single pieced of functionality just to avoid being accused of "not-invented-here".

Bad code is boring, because you quickly lose context or get confused by the 'bulldozer' approach that such code usually assumes.

So it won't help if you try and read it.

To paraphrase Tolstoy's quote about happy families: "All good code is alike, yet each bad code is bad in its own way".

I remember a piece of advice from some guru programmer I've read some time ago: "Don't just read the code - compile the program and try and change something in the code, maybe the window title, maybe add a menu item - something silly, but which forces you to figure out where things are done in code."

I think another way to put many of the items on your list is that the code should read as a description of what it intends to do, rather than how it intends to do it. Breaking code into components and giving those components useful names goes a long way towards achieving this goal.

For me, at least, this helps with the act of writing the code, in addition to the act of reading it. I am not nearly smart enough to keep in mind all of the things that need to be done to write solid code. So I compensate by developing abstractions that let me forget about details, assume they're handled (for the moment) and focus on just a small part of the problem at hand. The act of writing the code in that way tends to lead to a more manageable style.

> -Not concerned with issues such as performance, maintenability and security

This is where engineering sense comes into play. I'd personally rather not pay for things I don't need, particularly if an undue focus on performance, etc. means my cost overruns my budget. Perfect is the enemy of the good, and all that...

"This is where engineering sense comes into play. I'd personally rather not pay for things I don't need, particularly if an undue focus on performance, etc. means my cost overruns my budget. Perfect is the enemy of the good, and all that..."

I agree, however, making at least an effort is preferable than not caring.

What I had in mind was the developer of a legacy system at my previous work. He couldn't understand why I was fussing over performance metrics and I told him I couldn't understand how he could not. The reply was that they had enough trouble "making the bloody thing working", so anything else was peripheral.

For me, the question would be why you cared about the performance metrics. Sometimes bad performance can be a sign that something is fundamentally broken, and fixing the metrics might be the solution to the stability problem. Sometimes, it's less important and more of a distraction. Usually, it's not to difficult to put together a case that performance issues are impacting stability.

Reply on news.ycombinator.com