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

21–30 of 66 posts

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

#21

Post by DanielBMarkham »

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…

I have to disagree with #6. You can either write code for the compiler or the human. I prefer to write it for the human, because a lot of times the compiler understands exactly what's going on, but I'm pretty clueless when I come back after only a few days. I think you meant not understanding how the language works so using a lot of extra commands when one would do. However it's common to "dumb down" your code, especially if it is tricky, for the poor schmuck that has to maintain it. Remember -- writing code should not be like writing a mystery novel.

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

#22

Post by boucher »

omouse wrote: post #6
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…

0. You refuse to use recursion even when working with a language that supports it properly because you think it's horribly slow.

"a language that supports it properly..."

Meaning what exactly? A language that automatically optimized for tail recursion? Are there languages which don't support recursion "properly?"

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

#23

Post by tyler »

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…

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

I can certainly see how this is true in a large organization which hires lots of mediocre programmers. However, if you're in a company where the other programmers are top notch, this sort of thing is not a problem.

In fact, if I ever see nested ifs and such in a function where I work, it gets changed to the least number of lines of code possible. I can do this because there is only 1 other programmer here, and I know he's not going to screw it up.

I don't know your situation, obviously, but my initial reaction is... "Holy crap man... run!"

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

#24

Post by edw519 »

tyler wrote: post #23
edw519 wrote: post #13

Earlier quoted context omitted.

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

"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." I can certainly see how this is true in a large organization which hires lots of mediocre programmers. However, if you're in a company where the other programmers are top notch, this sort of thing is not a problem. In fact, if I ever see…

"if you're in a company where the other programmers are top notch"

I've never seen such a thing (and I've seen alot).

Reason #127 for starting your own.

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

#25

Post by Goladus »

edw519 wrote: post #15
Goladus wrote: post #12

Earlier quoted context omitted.

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

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

I don't have that idea. There is sometimes, though, a tradeoff between current needs and future needs; and that tradeoff can not always be predicted. When that happens, it's logical to give current demands priority.

I can't for example, predict whether a future maintainer of my code would prefer code written with multiple returns, or code that sets temporary values, or code that uses a set of nested ifs, or code that assigns function pointers to a matrix and calls code based on the indices. Each technique has potential drawbackss in terms of future maintainability, likelihood of errors, and speed of immediate implementation. Trying to guess what a future coder (other than myself) will think is just not important in that case.

Effective Principles can only be Established based on a given development environment, and it's the responsibility of those in charge of the environment to make sure the established principles are effective and followed by the developers.

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

#26

Post by nostrademons »

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…

That's why "return" (and "throw" and "assert") is syntax-highlighted in most editors. ;-)

Honestly, I've never had a case where I visually missed an early exit. Most of the time, such exits are guard statements, designed to bail out with an exception if some precondition isn't met. Most of the rest, they're "found it, don't need to do any more processing" and apparent from the logic. I'll usually mark the latter with a quick comment anyway, just to be sure I don't miss them.

And early returns let you apply additional invariants to your code. You've checked your preconditions and bailed if necessary; you don't need to worry that this array might be null. You've handled the 1-item base case; you don't need to worry about your recursive function blowing up. I find that broken invariants cause many, many more bugs than missing an exit and not executing code.

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

#27

Post by edw519 »

boucher wrote: post #17
edw519 wrote: post #13

Earlier quoted context omitted.

"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 pro…

"15 different programmers are rarely touching the same piece of code over any short or medium span of time"

I see it all the time. But then again, maybe I'm like the blind man with the elephant; I only know what I've encountered.

Wouldn't it be great if analysis was conducted properly, design specs were tight, functional specs were accurate, projects were managed properly, programmers were trained, resources were adequate, and the people paying the bills had a clue as to what they needed? I've never seen it. That may be why code gets modified so many times. I've even seen "quick & dirty" temporary programs still in production for 15 years. This is the world we have to deal with. That's why we adhere to structured programming principles: to save ourselves a whole lot of trouble down the road.

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

#28

Post by nostrademons »

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.

I usually follow the childhood adage "First time it's funny, second time it's silly, third time's a spanking." Probably better summed up as http://www.c2.com/cgi/wiki?ThreeStrikesAndYouRefactor. Problem is, after 2 repetitions you often don't know what the real abstraction behind the duplicated code is, and so you end up with convoluted objects or closures to swap out parts of behavior, while there's a more natural abstraction just around the corner. If you mercilessly refactor after only the first duplication, you might not see it after the second, because the original code has been abstracted enough that it doesn't look like the third repetition.

This also squares with a lot of IBM's experience in The Mythical Man Month, i.e. code needs at least three clients to really be reusable.

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

#29

Post by Goladus »

boucher wrote: post #19
edw519 wrote: post #16

Earlier quoted context omitted.

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

Are the costs of function call overhead worth worrying about?

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

#30

Post by Tichy »

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…

That's what the other rule is for, to not make functions span too many lines ;-)
Post reply on HN