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

Want to learn to code? Don't copy and paste, type out other people's code

shockoe.com

Post reply on HN
Print view View original

181–184 of 184 posts

Re: Want to learn to code? Don't copy and paste, type out other people's code

#181

Post by kragen »

robomartin wrote: post #177
KPLauritzen wrote: post #167

Earlier quoted context omitted.

COuld you elaborate a bit on what the benefit of the other representations in your example. I don't get it.

OK, I pulled colors as an example out of thin air but I'll see if I can make it work. Let's say you have to write a routine that does something based on a color as the input. You have a few choices in terms of how to represent the colors: - The name of the color in a string - A typdef enum for your colors (integers) - A color-per-bit scheme (U8, U16, U32) - Channel-per-bit scheme (U8) - 4 or 6 bit packed RGB values (…

I think it depends on a lot more of the circumstances than this. For example, in many languages, you can intern the strings so that a string equality test is just a single machine instruction. And if these color representations are crossing some interface that needs to be kept stable, it's a lot easier to add new colors if what's crossing is "red" or "#ff0000" than if it's "2". And it may be that what you're doing with the colors is just generating HTML, rather than doing multi-way switches, in which case the enum implementation has no advantage over the string representation; it just increases code duplication.

The probably more important consideration is that with an enum, your compiler can catch misspellings. Depending on your runtime environment, this can be a huge killer advantage. In particular, if your runtime environment can't do much beyond blink an LED to report errors, compile-time checking is really really important.

Re: Want to learn to code? Don't copy and paste, type out other people's code

#182

Post by robomartin »

kragen wrote: post #181
robomartin wrote: post #177

Earlier quoted context omitted.

OK, I pulled colors as an example out of thin air but I'll see if I can make it work. Let's say you have to write a routine that does something based on a color as the input. You have a few choices in terms of how to represent the colors: - The name of the color in a string - A typdef enum for your colors (integers) - A color-per-bit scheme (U8, U16, U32) - Channel-per-bit scheme (U8) - 4 or 6 bit packed RGB values (…

I think it depends on a lot more of the circumstances than this. For example, in many languages, you can intern the strings so that a string equality test is just a single machine instruction. And if these color representations are crossing some interface that needs to be kept stable, it's a lot easier to add new colors if what's crossing is "red" or "#ff0000" than if it's "2". And it may be that what you're doing wi…

I think we are slicing this a little too thin. My original point is that it is important to understand that the choices made when representing data can be important. My off-the-hip example was not meant to be definitive.

Re: Want to learn to code? Don't copy and paste, type out other people's code

#183

Post by teach »

keithpeter wrote: post #144
teach wrote: post #69

Earlier quoted context omitted.

I'm a high school computer science teacher, and this is a WONDERFUL idea. I'm totally going to steal it and create a few assignments based on the concept.

I teach Maths (in the UK), so pinch of salt needed with my suggestion below... Suggestion: code fragment on your interactive whiteboard. Ask students what each line does , how the loop works &c. Then blank the screen and get them to replicate....

Good idea but wouldn't work for me since I don't lecture anymore.
Post reply on HN