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

Signs You're a Crappy Programmer (and don't know it)

damienkatz.net

Post reply on HN
Print view View original

11–20 of 66 posts

Re: Signs You're a Crappy Programmer (and don't know it)

#11

Post by edw519 »

boucher wrote: post #7
edw519 wrote: post #5

10 Real Signs You're a Crappy Programmer: 10. The exact same code is in multiple places because you didn't bother to put in into a common function. 9. You have error codes in functions, but never bother to look at them (a sure sign that testing was never finished). 8. You have early exits from loops because you don't know how to properly code a recursion. 7. You execute too much code because you don't know the differ…

"8. You have early exits from loops because you don't know how to properly code a recursion." Wow. Not every problem calls for recursion. If you really hate early exits from loops, maybe you should just code the loop's condition differently.

"If you really hate early exits from loops, maybe you should just code the loop's condition differently."

Exactly.

Like I mentioned before, I'm the poor schmuck that has to clean it up because someone didn't bother to take your (common sense) advice years ago.

Re: Signs You're a Crappy Programmer (and don't know it)

#12

Post by Goladus »

edw519 wrote: post #10
Goladus wrote: post #8

Earlier quoted context omitted.

(6) Happens even when you know better. (10) Good programmers don't repeat themselves, true, and to continually improve as a programmer it is important to patiently do everything correctly the first time. However, obsessing over a few bits of code duplication is often a complete waste of time.

"...obsessing over a few bits of code duplication is often a complete waste of time." For you, maybe. But what about the guy who applies enhancements 3 years later and has trouble getting through testing because the exact same code was somewhere else and difficult to find because of the 67 mods since then. Minutes "obsessing" today usually saves hours testing tomorrow.

"Minutes "obsessing" today usually saves hours testing tomorrow."

True, but the app has to make it to tomorrow for testing to matter at all. It's better to be in the championship trying to figure out how to manage a tired team, than it is to conserve energy during the semifinals and wind up sitting in the bleachers.

Re: Signs You're a Crappy Programmer (and don't know it)

#13

Post by edw519 »

boucher wrote: post #9
edw519 wrote: post #4

"...and it often simplifies the code to have multiple returns." Today. And what happens after 10 other programmers modify your slick little multi-return function? Nobody will ever be able to modify it again because the entries and exits are lost among the garbage. This is the ongoing debate I've had for years with "clever programmers". They're missing one critical point: the guidelines of structured programming are n…

Early returns make code more readable. I'd rather detect an error and bail then have a slew of nested ifs. It isn't always about being clever.

"I'd rather detect an error and bail then have a slew of nested ifs."

And here's what inevitably happens when you do that:

14 mods are applied and your early exit(s) get lost in the muck.

Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months.

Then I come along, find the errors, fix the data base, advise the user of the effects of the damage, and rewrite the whole program with single entry/single exit processing so that this never happens again. And then post to a board like this only to re-engage in the same old debate.

Aside from poorly named variables, violation of "single entry/single exit" is the biggest lifespan reducing problem of code bases I've ever seen.

This is the future speaking. Please don't do that.

Re: Signs You're a Crappy Programmer (and don't know it)

#14

Post by boucher »

edw519 wrote: post #11
boucher wrote: post #7

Earlier quoted context omitted.

"8. You have early exits from loops because you don't know how to properly code a recursion." Wow. Not every problem calls for recursion. If you really hate early exits from loops, maybe you should just code the loop's condition differently.

"If you really hate early exits from loops, maybe you should just code the loop's condition differently." Exactly. Like I mentioned before, I'm the poor schmuck that has to clean it up because someone didn't bother to take your (common sense) advice years ago.

Sometimes it makes more sense to bail early than it would to restructure. It could be that its more readable, or a more natural progression of things. Take this paper:

http://www.csd.uwo.ca/~yuri/Papers/pami04.pdf

It's really great, for the record. Anyway, the algorithm they wrote uses an early exit. In fact, they use a while(true), the "worst case" example.

    initialize: S = {s}, T = {t}, A = {s, t}, O = {(Empty Set)} 
    while true 
        grow S or T to find an augmenting path P from s to t 
        if P = {(Empty Set)} terminate 
        augment on P 
        adopt orphans 
    end while
In programming this algorithm, sure, I could probably move the first grow before the loop, and grow at the end. But, now its harder to understand, and violates the afore mentioned copy paste rule.

My point is this, take any such "rule" with a grain of salt. There are plenty of examples where it makes sense to do something atypical.

Re: Signs You're a Crappy Programmer (and don't know it)

#15

Post by edw519 »

Goladus wrote: post #12
edw519 wrote: post #10

Earlier quoted context omitted.

"...obsessing over a few bits of code duplication is often a complete waste of time." For you, maybe. But what about the guy who applies enhancements 3 years later and has trouble getting through testing because the exact same code was somewhere else and difficult to find because of the 67 mods since then. Minutes "obsessing" today usually saves hours testing tomorrow.

"Minutes "obsessing" today usually saves hours testing tomorrow." True, but the app has to make it to tomorrow for testing to matter at all. It's better to be in the championship trying to figure out how to manage a tired team, than it is to conserve energy during the semifinals and wind up sitting in the bleachers.

Where'd you ever get the idea that there is any trade-off between "quick" and "right"?

Doing things according to effective established principles saves a little time today and a lot of time tomorrow.

Quick and dirty usually ends up being neither.

Re: Signs You're a Crappy Programmer (and don't know it)

#16

Post by edw519 »

boucher wrote: post #14
edw519 wrote: post #11

Earlier quoted context omitted.

"If you really hate early exits from loops, maybe you should just code the loop's condition differently." Exactly. Like I mentioned before, I'm the poor schmuck that has to clean it up because someone didn't bother to take your (common sense) advice years ago.

Sometimes it makes more sense to bail early than it would to restructure. It could be that its more readable, or a more natural progression of things. Take this paper: http://www.csd.uwo.ca/~yuri/Papers/pami04.pdf It's really great, for the record. Anyway, the algorithm they wrote uses an early exit. In fact, they use a while(true), the "worst case" example. initialize: S = {s}, T = {t}, A = {s, t}, O = {(Empty Set)}…

"violates the afore mentioned copy paste rule"

Put it in a common function. Sure, it may look a little frazzled today, but generations of future hackers will thank you.

Re: Signs You're a Crappy Programmer (and don't know it)

#17

Post by boucher »

edw519 wrote: post #13
boucher wrote: post #9

Earlier quoted context omitted.

Early returns make code more readable. I'd rather detect an error and bail then have a slew of nested ifs. It isn't always about being clever.

"I'd rather detect an error and bail then have a slew of nested ifs." And here's what inevitably happens when you do that: 14 mods are applied and your early exit(s) get lost in the muck. Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months. Then I come along, find the errors, fix the data ba…

I see where you are coming from, but I'm just not buying it. First, 15 different programmers are rarely touching the same piece of code over any short or medium span of time. Second, even over the long term, if you have programmers who don't read the code they are making changes to before they change it, you should fire them.

You can make the same argument that a bunch of nested ifs is going to end up with a lazy programmer who doesn't know what conditions need to be met, so he puts it in the wrong place, and now all of your careful code is broken. Coding style is ultimately pretty personal, and this is no different.

Re: Signs You're a Crappy Programmer (and don't know it)

#18

Post by Goladus »

edw519 wrote: post #13
boucher wrote: post #9

Earlier quoted context omitted.

Early returns make code more readable. I'd rather detect an error and bail then have a slew of nested ifs. It isn't always about being clever.

"I'd rather detect an error and bail then have a slew of nested ifs." And here's what inevitably happens when you do that: 14 mods are applied and your early exit(s) get lost in the muck. Programmer 15 puts his mod ON THE WRONG SIDE of your early exit because he never saw it. He doesn't do regression testing, and the data base gets screwed up over the next 6 months. Then I come along, find the errors, fix the data ba…

Questions I have would be:

Why is the function being modified 14 times? It sounds like the original abstraction was poorly conceived. I would hope that at some point before edit #15, someone would think to break the function down into smaller pieces.

Re: Signs You're a Crappy Programmer (and don't know it)

#19

Post by boucher »

edw519 wrote: post #16
boucher wrote: post #14

Earlier quoted context omitted.

Sometimes it makes more sense to bail early than it would to restructure. It could be that its more readable, or a more natural progression of things. Take this paper: http://www.csd.uwo.ca/~yuri/Papers/pami04.pdf It's really great, for the record. Anyway, the algorithm they wrote uses an early exit. In fact, they use a while(true), the "worst case" example. initialize: S = {s}, T = {t}, A = {s, t}, O = {(Empty Set)}…

"violates the afore mentioned copy paste rule" Put it in a common function. Sure, it may look a little frazzled today, but generations of future hackers will thank you.

You're still making two function calls when you could be making one. If one of them gets lost in the fray, you'll spend just as much time solving that problem.

Re: Signs You're a Crappy Programmer (and don't know it)

#20

Post by DanielBMarkham »

Goladus wrote: post #8
edw519 wrote: post #5

10 Real Signs You're a Crappy Programmer: 10. The exact same code is in multiple places because you didn't bother to put in into a common function. 9. You have error codes in functions, but never bother to look at them (a sure sign that testing was never finished). 8. You have early exits from loops because you don't know how to properly code a recursion. 7. You execute too much code because you don't know the differ…

(6) Happens even when you know better. (10) Good programmers don't repeat themselves, true, and to continually improve as a programmer it is important to patiently do everything correctly the first time. However, obsessing over a few bits of code duplication is often a complete waste of time.

"obsessing over a few bits of code duplication..."

Applying good coupling and cohesion principles is not obsessing. It's as much legitimate programming as writing an equality test.

Post reply on HN