4 ms·

MP3 importing code for the Audacity audio editor. I wrote this in 2002. https://github.com/audacity/audacity/blob/master/src/import/ImportMP3.cpp https://gith

MP3 importing code for the Audacity audio editor. I wrote this in 2002. https://github.com/audacity/audacity/blob/master/src/import/ImportMP3.cpp https://github.com/audacity/audacity/blob/master/src/import/... Amusingly, a TODO I put is still there: /* TODO: get rid of this by adding fixed-point support to SampleFormat. * For now, we allocate temporary float buffers to convert the fixed * point samples into something we can feed to the WaveTrack. Allocating * big blocks of data like this isn't a great idea, but it's temporary. */ "temporary" indeed. :)

nickpsecurity 10y ago
A great example of why we tell people to forget using a substandard approach and language for "quick and dirty code that will probably get thrown away." A lot of long-lasting code started out exactly that way. ;)
- allan_s 10y ago
  my way to approach this, be it for my hobby or corporate projects, is to always associate a TODO with a ticket/issue number (in github/redmine/jira/whatever) so that I can remember them, and/or include them in a sprint (in my company I always try to include one or two "fix todo" issues in our sprints) It also helps teammate who find themselves with 1 hours idleing to have a little thing to do.
  - nickpsecurity 10y ago
    That's a good idea. Long as it gets done. Capitalizing on downtime makes it an even better idea. :)
- dagss 10y ago
  You neglect something I think is very important: You do not normally know up front what code will live and not. If you carefully (over-)engineer everything you will perhaps not get time to write all those short-lived failures that preceded that long-lasting success. Of course I wish that piece of code that I hacked 3 years ago and never got around to refactor was better done the first time! But that kind of thinking ignores the fact that if my mentality had been "perfect up front" then what I would have spent all my time perfecting was the previous piece of code, the one I have long since deleted. I never would have gotten around to writing the hacky code I kept.
  - hikarudo 10y ago
    Survivorship bias.
    - itsthecourier 10y ago
      But HE survived
  - nickpsecurity 10y ago
    "You neglect something I think is very important: You do not normally know up front what code will live and not." It's actually mentioned in my post and the whole point. "If you carefully (over-)engineer everything you will perhaps not get time" This is true. You can spend vast amounts of over-engineering instead of hacking something together that's "perfect up front." This is a false dilemma, though, as simply taking a little more time to think about or improve some code can work wonders. Better instead of perfect. You will still output less code but you'll have more useful and correct code.
    - dagss 10y ago
      I was answering to "using a substandard approach and language" -- if that is an option that's on the table I am assuming the time savings would be substantial (order of 50%). I do of course agree that one should often "Taking a little more time to think about or improve some code". It seems like you almost say that it is better to be good at coding than bad at coding. Which I think nobody will ever disagree with. What I was talking about was assuming senior coders, knowing what they are doing, who think about actively choosing a shortcut. I don't think it's a strict dichotomy, but I think there is a scale. For every project you can choose how well to do the job, and compare it to the importance the task seem to have and the budget it ought to have in developer time spent on it; then find relevant short-cut which does not dig you too much deeper in the hole. I usually try to figure out "how would I refactor this later to clean it up", make sure it can be done without too much pain, then if I can see the path clearly it's OK to take the shortcut if needed.
  - matt_wulfeck 10y ago
davemac 10y ago
Was going to prison related to this software?
- spb 10y ago
  I think you're confusing this comment with the one ranked above it.
atom-morgan 10y ago
I just recently started using Audacity. So thanks!
pvorb 10y ago
“There's nothing more permanent than a temporary hack.” - Kyle Simpson (via @CodeWisdom)

nickpsecurity 10y ago

A great example of why we tell people to forget using a substandard approach and language for "quick and dirty code that will probably get thrown away." A lot of long-lasting code started out exactly that way. ;)

allan_s 10y ago
my way to approach this, be it for my hobby or corporate projects, is to always associate a TODO with a ticket/issue number (in github/redmine/jira/whatever) so that I can remember them, and/or include them in a sprint (in my company I always try to include one or two "fix todo" issues in our sprints) It also helps teammate who find themselves with 1 hours idleing to have a little thing to do.
- nickpsecurity 10y ago
  That's a good idea. Long as it gets done. Capitalizing on downtime makes it an even better idea. :)
dagss 10y ago
You neglect something I think is very important: You do not normally know up front what code will live and not. If you carefully (over-)engineer everything you will perhaps not get time to write all those short-lived failures that preceded that long-lasting success. Of course I wish that piece of code that I hacked 3 years ago and never got around to refactor was better done the first time! But that kind of thinking ignores the fact that if my mentality had been "perfect up front" then what I would have spent all my time perfecting was the previous piece of code, the one I have long since deleted. I never would have gotten around to writing the hacky code I kept.
- hikarudo 10y ago
  Survivorship bias.
  - itsthecourier 10y ago
    But HE survived
- nickpsecurity 10y ago
  "You neglect something I think is very important: You do not normally know up front what code will live and not." It's actually mentioned in my post and the whole point. "If you carefully (over-)engineer everything you will perhaps not get time" This is true. You can spend vast amounts of over-engineering instead of hacking something together that's "perfect up front." This is a false dilemma, though, as simply taking a little more time to think about or improve some code can work wonders. Better instead of perfect. You will still output less code but you'll have more useful and correct code.
  - dagss 10y ago
    I was answering to "using a substandard approach and language" -- if that is an option that's on the table I am assuming the time savings would be substantial (order of 50%). I do of course agree that one should often "Taking a little more time to think about or improve some code". It seems like you almost say that it is better to be good at coding than bad at coding. Which I think nobody will ever disagree with. What I was talking about was assuming senior coders, knowing what they are doing, who think about actively choosing a shortcut. I don't think it's a strict dichotomy, but I think there is a scale. For every project you can choose how well to do the job, and compare it to the importance the task seem to have and the budget it ought to have in developer time spent on it; then find relevant short-cut which does not dig you too much deeper in the hole. I usually try to figure out "how would I refactor this later to clean it up", make sure it can be done without too much pain, then if I can see the path clearly it's OK to take the shortcut if needed.
- matt_wulfeck 10y ago

davemac 10y ago

Was going to prison related to this software?

spb 10y ago
I think you're confusing this comment with the one ranked above it.

atom-morgan 10y ago

I just recently started using Audacity. So thanks!

pvorb 10y ago

“There's nothing more permanent than a temporary hack.” - Kyle Simpson (via @CodeWisdom)