5 ms·

I appreciate your meaning; certainly, there are enough weak essays about bad programmers, but this one has more substance than some I've read. The idea behind

I appreciate your meaning; certainly, there are enough weak essays about bad programmers, but this one has more substance than some I've read. The idea behind any essay about bad programming has merit. I read the points in essay like this through two filters: is it a valid point and am I guilty of it. Most of the points in this essay are valid. The one about pointers isn't so relevant unless you live in C but the others, sure. The bit about knowing your platform well - that made me think about some things I've been working on. The essay made me think and maybe checksum myself just a bit. For that, I like it.

Zancarius 17y ago
> The one about pointers isn't so relevant unless you live in C but the others, sure. To be fair to the article's author, he does mention that understanding references is analogous to understanding pointers. They aren't the same thing (his own words) but they're close enough to matter. I confess I originally thought exactly as you did: "What? This only applies to languages like C!" until I read a little more closely. It was a tricky sentence, and I would have appreciated it more if he were to have made the two a little more obvious. It's always easier to judge in retrospect, though. The problem I have is that I agree with you and the original individual who stated that the article seemed arrogant. On the one hand, it made some really good points including MANY that I have been guilty of at some point or another. The biggest beef I have with the article at large is that some of the issues are language-specific. For instance, not using methods/fields "correctly" is a pretty big problem--unless you're using a language that doesn't have properties (hello, PHP). I absolutely love properties, but whenever I've had to maintain or write PHP (yeah, I know), I tend to create public fields and use them as a pseudo-property rather than writing getter/setter methods. One, since it's a scripting language, getter/setters are superfluous for most simple applications and the fact that it's a dynamic language with an extremely stupid typing system sort of mitigates the benefit of writing extra code. I'm also not sure whether there's a performance penalty with accessor and mutator methods (maybe someone can clue me in here) in PHP. So, am I a bad programmer because I don't use standard paradigms for small scripts written in an arguably awful language? Maybe so. Maybe more so since I actually write in that language from time to time! But, the point of this minor tangent is that some of the article's points don't effectively apply in all languages either due to deficiencies or oversights in the language specification. I do appreciate your point about reading the article through two filters. I'd like to add a couple of others: does it matter (in the context of the language you're using) and is the point of contention a mistake that could be made due to scheduling pressure or deadlines? To some extent, I'm sure we could blame a specific degree of bad code on ridiculous deadlines (and I think the author pointed that out, too!).

Zancarius 17y ago

> The one about pointers isn't so relevant unless you live in C but the others, sure. To be fair to the article's author, he does mention that understanding references is analogous to understanding pointers. They aren't the same thing (his own words) but they're close enough to matter. I confess I originally thought exactly as you did: "What? This only applies to languages like C!" until I read a little more closely. It was a tricky sentence, and I would have appreciated it more if he were to have made the two a little more obvious. It's always easier to judge in retrospect, though. The problem I have is that I agree with you and the original individual who stated that the article seemed arrogant. On the one hand, it made some really good points including MANY that I have been guilty of at some point or another. The biggest beef I have with the article at large is that some of the issues are language-specific. For instance, not using methods/fields "correctly" is a pretty big problem--unless you're using a language that doesn't have properties (hello, PHP). I absolutely love properties, but whenever I've had to maintain or write PHP (yeah, I know), I tend to create public fields and use them as a pseudo-property rather than writing getter/setter methods. One, since it's a scripting language, getter/setters are superfluous for most simple applications and the fact that it's a dynamic language with an extremely stupid typing system sort of mitigates the benefit of writing extra code. I'm also not sure whether there's a performance penalty with accessor and mutator methods (maybe someone can clue me in here) in PHP. So, am I a bad programmer because I don't use standard paradigms for small scripts written in an arguably awful language? Maybe so. Maybe more so since I actually write in that language from time to time! But, the point of this minor tangent is that some of the article's points don't effectively apply in all languages either due to deficiencies or oversights in the language specification. I do appreciate your point about reading the article through two filters. I'd like to add a couple of others: does it matter (in the context of the language you're using) and is the point of contention a mistake that could be made due to scheduling pressure or deadlines? To some extent, I'm sure we could blame a specific degree of bad code on ridiculous deadlines (and I think the author pointed that out, too!).