4 ms·

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 (th

by JCDenton2052 10y ago

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.

mschaef 10y ago
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...
- JCDenton2052 10y ago
  "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.
  - mschaef 10y ago
    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.
mybrid 10y ago
"-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".
delegate 10y ago
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."

mschaef 10y ago

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...

JCDenton2052 10y ago
"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.
- mschaef 10y ago
  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.

mybrid 10y ago

"-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".

delegate 10y ago

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."