How to be a better programmer in 6 minutes • Hacker News Board

Re: How to be a better programmer in 6 minutes

#41

Post by jlouis » Mon, Feb 09, 2009, 10:00 AM UTC

jrockway wrote: post #36

gnaritas wrote: post #34

Earlier quoted context omitted.

He was talking about writing short methods to begin with, not fixing the already borked ones.

Yeah, great advice. Programmers should also stop writing bugs, too. How hard is it to GET IT RIGHT THE FIRST TIME?! All this bug hunting (and fixing) is a time waster. (Sarcasm alert.)

Heh, but fact is that not adding the bug in the first place is better than spending time fixing it later. So you must catch problems quickly and attack them swiftly.

There is a nice self-regulation principle at work here: If you make software with a lot of bugs, you also spend time fixing those bugs. This hampers your ability to make more crap software. If you on the other hand produce quality software, much less time is spent at maintenance so you become more productive overall.

I think it is a fallacy to expect bugs to creep into your code. Eradicate them before writing the code lines. But what makes this hard for most people is that you don't think you need that amount of quality in your software.

Re: How to be a better programmer in 6 minutes

#42

Post by greml1n » Mon, Feb 09, 2009, 1:24 PM UTC

I am going to master the goto keyword.

Re: How to be a better programmer in 6 minutes

#43

Post by Anon84 » Mon, Feb 09, 2009, 2:02 PM UTC

Bjoern wrote: post #24

Why a article with such a provocative headline (and so little content) makes the top here at HN is a riddle for me. Might have something to do with the fact that the HN Rules have been floating around too, namely alot of new people around. (Sorry for digressing.) Coming back to the article I want to mention some points. (Maybe some things are biased..) Ref. 1.) While a bigger font size is good for your eyes (hope you…

Ref. 2.) Making a syntax element like hard coded strings so much stand out is contra productive in my opinion. It would be much smarter to focus on emphasizing the important aspects of your code rather than over-highlighting strings.

Well... nature works by killing what's bad (extinction) and not simply duplicating what's good (say, cloning). Removing errors improves the final product, copying what seems to be better at a given point in time limits the possibilities and eventually leads to disaster.

Re: How to be a better programmer in 6 minutes

#44

Post by jff » Mon, Feb 09, 2009, 2:15 PM UTC

8. Stop reading, start writing.

No. How about "8. Stop writing, start thinking." Plan a little bit before you start smashing out code.

Also, regarding number 5, go read the Plan 9 source for insight into clean style and tight code: http://csplan9.rit.edu/magic/webls?dir=/sys/

Re: How to be a better programmer in 6 minutes

#45

Post by rrival » Mon, Feb 09, 2009, 4:30 PM UTC

tolmasky wrote: post #13

Bigger text size is also good for not going blind. I've been coding with bigger text for a few months now, fewer headaches too.

Hadn't even thought to do this and loving it so far today.

Re: How to be a better programmer in 6 minutes

#46

Post by anamax » Mon, Feb 09, 2009, 4:57 PM UTC

nostrademons wrote: post #29

paul wrote: post #22

Why would I not "hard code" strings? These suggestions don't seem that great to me. How about learning to type with your feet, or only using the mouse, or maybe code blindfolded? (or all three!) Somehow, people seem to have gotten the notion that doing things the hard way is somehow better or morally superior or something. It's not.

It's often good to try things the hard way and then go back to doing it the easy way once you've mastered that. The easy way seems so much easier once you've done otherwise. The "ugly strings" suggestion is bizarre, though. If he means "avoid hardcoded strings so you can localize your program", then you still need keys into your message catalog, which are usually...strings! And if he means "define constants for strin…

The reason for "ugly strings" is that the value for named constants can be changed at a single location.

If a given constant appears in multiple locations, you're likely to screw up when you need to change its value. (Nope - global search and replace doesn't help - it will change semantically unrelated constants that happen to have the exact same value. Consider 0.)

Re: How to be a better programmer in 6 minutes

#47

Post by nostrademons » Tue, Feb 10, 2009, 3:37 AM UTC

anamax wrote: post #46

nostrademons wrote: post #29

Earlier quoted context omitted.

It's often good to try things the hard way and then go back to doing it the easy way once you've mastered that. The easy way seems so much easier once you've done otherwise. The "ugly strings" suggestion is bizarre, though. If he means "avoid hardcoded strings so you can localize your program", then you still need keys into your message catalog, which are usually...strings! And if he means "define constants for strin…

The reason for "ugly strings" is that the value for named constants can be changed at a single location. If a given constant appears in multiple locations, you're likely to screw up when you need to change its value. (Nope - global search and replace doesn't help - it will change semantically unrelated constants that happen to have the exact same value. Consider 0.)

Two cases:

1.) The string in question has an observable effect on the application's behavior, eg. a filename or text that appears in the UI.

2.) The string in question is used as a programmatic key; its actual value matters to you for readability's sake, but the user doesn't know or care what its value is.

For #1, you should be using some sort of localizable message catalog (eg. gettext or Java property bundles) or config file and not hardcoding it as a constant. Almost all of these use strings as the message key; in gettext's case, they just happen to be fairly human-readable strings. Converting them to a constant merely goes from one suboptimal solution to another.

For #2, the particular string used is part of the internal API of the program. Coding it as a constant buys you a little in that you can get the compiler to check it for you and make sure you didn't make any typos. The difference is really the old static vs. dynamic language debate. In any case, changing the string value here should be considered a program refactoring and done the same way you would do any other refactoring.

Re: How to be a better programmer in 6 minutes

#48

Post by anamax » Tue, Feb 10, 2009, 4:38 PM UTC

nostrademons wrote: post #47

anamax wrote: post #46

Earlier quoted context omitted.

The reason for "ugly strings" is that the value for named constants can be changed at a single location. If a given constant appears in multiple locations, you're likely to screw up when you need to change its value. (Nope - global search and replace doesn't help - it will change semantically unrelated constants that happen to have the exact same value. Consider 0.)

Two cases: 1.) The string in question has an observable effect on the application's behavior, eg. a filename or text that appears in the UI. 2.) The string in question is used as a programmatic key; its actual value matters to you for readability's sake, but the user doesn't know or care what its value is. For #1, you should be using some sort of localizable message catalog (eg. gettext or Java property bundles) or c…

> not hardcoding it as a constant.

The bits have to be somewhere. The question is whether they appear one place per "meaning" or they're at every use.

Normalization is not just for databases.

> In any case, changing the string value here should be considered a program refactoring and done the same way you would do any other refactoring.

Which refactoring tools can distinguish "obj" (used as a prefix for object file temp names) from "obj" (used as a prefix for orange bear jumpsuit part numbers), let alone 0 from 0?