Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signs that you're a bad programmer

sites.google.com

Post reply on HN
Print view View original

101–110 of 131 posts

Re: Signs that you're a bad programmer

#101

Post by sfk »

torpor wrote: post #81
sfk wrote: post #80

Earlier quoted context omitted.

Good advice, but compilers often issue warnings like "x may be used uninitialized" even when it cannot happen.

Erm, wut? Not really. If there is a warning, its there for a reason. Fix that.

As everyone who has written a C program of sufficient complexity knows, these warnings are not always correct. Google for "spurious warnings uninitialized", e.g:

http://kerneltrap.org/node/6591

An unrelated example where gcc (and icc) emit needless warnings about integer types is this:

  int x = foo();
  unsigned y = (x == 0);
Don't get me wrong, I'm in favor of cranking up the warning levels, but there is a reason why not everything is included in -Wall (yes, "uninitialized" is included, I know).

Re: Signs that you're a bad programmer

#102

Post by NoHandle »

High cohesion is bad in exactly which programming environment? Functional or procedural?

I've always understood high cohesion to be related to low coupling. Also, writing util classes before you need them (where low cohesion may be necessary) is a nothing more than a time sink. Do something when you need it, not before. You are not omniscient and will not be able to account for everything no matter how hard you try.

Re: Signs that you're a bad programmer

#103

Post by scott_s »

dionidium wrote: post #55
321abc wrote: post #36

The author lists the following as a symptom of being "unable to reason about code": "5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)" I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some poin…

Sometimes the (seemingly) simple act of trying to come up with a name for a subroutine helps me reason about what it is I'm trying to do (whether the chunk is re-usable or not).

Not being able to think of a good name for a variable, function, class or data structure is a show-stopper for me. If I can't come up with a short, descriptive name, then I assume I don't really understand what I want that thing to do or be. I'll sit and think until I'm satisfied I have both a meaningful name and a grasp on how this thing fits into the problem.

Re: Signs that you're a bad programmer

#104

Post by jimbokun »

scottdw2 wrote: post #71

I have to say, I really didn't like the document much. Not because of substance. Some of what he says is true. On style, though, I think the document is trash. Some of what I say is probably even a bit ad hominem. Most of the good programmers I know don't spend time worrying about bad programmers. They just write good code and cleanup bad code when they see it. If someone feels compelled to write up an essay about ba…

"The best way to "be", and to be recognized as, a good programmer is to write good code."

That is why he included "remedies" for each condition. If you implement all of these remedies, you are very likely to write good code, and thus be a good programmer.

The title leads to the structure of the article, which is really about pitfalls to avoid if you want to be a good programmer. And for some, the negative tone might really be necessary. Remember, incompetent people are often unaware of their own incompetence. But if someone has the humility to read an article titled "Signs that you're a bad programmer" and honestly look for things he can identify in himself, he is on the right track.

In my opinion, the remedies transform this from an attempt at vilifying outsiders, into a potentially valuable tool for becoming a better programmer.

Re: Signs that you're a bad programmer

#105

Post by jamesbritt »

kevindication wrote: post #91
dionidium wrote: post #55

Earlier quoted context omitted.

Sometimes the (seemingly) simple act of trying to come up with a name for a subroutine helps me reason about what it is I'm trying to do (whether the chunk is re-usable or not).

I don't know if you've tried this, but if you write down some pseudocode before you really get started, the logical chunks of the program will take their names straight from the pseudocode.

Or do comment-driven development: write the comments for the method first, then convert the (hopefully!) plain English into code, ideally so that no comment is needed.

Re: Signs that you're a bad programmer

#106

Post by timwiseman »

321abc wrote: post #36

The author lists the following as a symptom of being "unable to reason about code": "5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)" I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some poin…

I agree with you, but I think that when it is possible to break it into atomic functions that are reusable then that is superior to doing it simply for size reasons.

Re: Signs that you're a bad programmer

#107

Post by mgreenbe »

ardit33 wrote: post #62

After reading it twice, there are many points that are good, but there also some points that are not so clear cut, or plain bad. Maybe I am a bad programmer, but I disagree with some points: # (OOP) Writing lots of "xxxxxManager" classes that contain all of the methods for manipulating the fields of objects that have little or no methods of their own I guess they keyword 'lots' make this ok, but having plain objects…

  Recursive subroutines that concatenate/sum to a global 
  variable or a carry-along output variable
Wow...I didn't see this in the article. That is downright boneheaded. Is accumulator-passing style forbidden for a reason? It's a cheap way to make functions tail-recursive---much cheaper than CPS!

Re: Signs that you're a bad programmer

#108

Post by ratsbane »

scottdw2 wrote: post #71

I have to say, I really didn't like the document much. Not because of substance. Some of what he says is true. On style, though, I think the document is trash. Some of what I say is probably even a bit ad hominem. Most of the good programmers I know don't spend time worrying about bad programmers. They just write good code and cleanup bad code when they see it. If someone feels compelled to write up an essay about ba…

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.

Re: Signs that you're a bad programmer

#109

Post by 321abc »

kaitnieks wrote: post #79
321abc wrote: post #36

The author lists the following as a symptom of being "unable to reason about code": "5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)" I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some poin…

I'm not fond of scrolling (or ctrl+clicking) up and down to see what every little subroutine does to understand the code I have to fix. Only if it's my own code, I can be somewhat sure the tiny function does indeed SetOrderDate, but maybe it also modifies order's XML or changes some global variables... I can never be sure and I have to look, so reading bulldozed code is almost like reading huge routine but with way m…

Using ctags and a good editor (or an IDE) will make the process of seeking to (and jumping back from) subroutines a lot less painful.

Re: Signs that you're a bad programmer

#110

Post by clawrencewenham »

mgreenbe wrote: post #107
ardit33 wrote: post #62

After reading it twice, there are many points that are good, but there also some points that are not so clear cut, or plain bad. Maybe I am a bad programmer, but I disagree with some points: # (OOP) Writing lots of "xxxxxManager" classes that contain all of the methods for manipulating the fields of objects that have little or no methods of their own I guess they keyword 'lots' make this ok, but having plain objects…

Recursive subroutines that concatenate/sum to a global variable or a carry-along output variable Wow...I didn't see this in the article. That is downright boneheaded. Is accumulator-passing style forbidden for a reason? It's a cheap way to make functions tail-recursive---much cheaper than CPS!

I'm still looking for a good way to express what was meant by that symptom description.

You know about tail recursion, but I'm trying to get at the uses of accumulators that have nothing to do with tail recursion.

That and I got fed up with listing all of the exceptions to every rule.

Post reply on HN