211–220 of 243 posts
Earlier quoted context omitted.
What's worse is when fake delays are put into the code because (stupid) people think that the computer can't possibly be doing a good job if it retrieves the results in under a second. If it's "thinking", it's working well!
I thought the fake delays were so the programmer could cash in on doing optimisations at a later date.
Every single legacy application I've ever worked on has had analogous code buried in it somewhere. An application I've just been "repairing" recently has a spot where it uses two separate queries to pull two full table sized lists of values, then manually joins them with a loop, and then manually re-orders the joined values into groups selectively ignoring some rows, and then embeds the the whole reordered list in a…
I'm starting to really dislike the term "legacy code". It implies the code is bad because it's old. It perpetuates the misconception that code gets "stale" and problems build up. But that's not true. "Legacy code" is bad because it's BAD. All code is "legacy code" because unless the project is brand new, it has some history. We just don't call good old code "legacy code" because it hasn't caused us any problems. Ther…
Earlier quoted context omitted.
I'm starting to really dislike the term "legacy code". It implies the code is bad because it's old. It perpetuates the misconception that code gets "stale" and problems build up. But that's not true. "Legacy code" is bad because it's BAD. All code is "legacy code" because unless the project is brand new, it has some history. We just don't call good old code "legacy code" because it hasn't caused us any problems. Ther…
In 'Working with Legacy Code', Michael Feathers defines legacy code as code without sufficient tests. The great thing about this definition is that it doesn't matter how old the code is - if it can be changed without worry about introducing unwanted behaviour because of test coverage, then it's not legacy. It also means that you can write new legacy code right now!
I once made the argument that a team within my organization was actively producing new legacy code. It wasn't my most diplomatic moment.
Earlier quoted context omitted.
I tend to spend a lot of time planning (almost as much as coding). I do tend to notice big changes over a period of 2-3 years but areas where I can notice improvements in say six months.
I think I spend too much time planning and not enough time just getting shit done. It's one of the things that I feel like I have to work on this year.
But what this means is I rarely come in the next week and wonder what I was thinking (it does happen, but rarely). More often I look at things, over a few months figure out better solutions to coding problems and my style changes accordingly.
Every single legacy application I've ever worked on has had analogous code buried in it somewhere. An application I've just been "repairing" recently has a spot where it uses two separate queries to pull two full table sized lists of values, then manually joins them with a loop, and then manually re-orders the joined values into groups selectively ignoring some rows, and then embeds the the whole reordered list in a…
I'm starting to really dislike the term "legacy code". It implies the code is bad because it's old. It perpetuates the misconception that code gets "stale" and problems build up. But that's not true. "Legacy code" is bad because it's BAD. All code is "legacy code" because unless the project is brand new, it has some history. We just don't call good old code "legacy code" because it hasn't caused us any problems. Ther…
Earlier quoted context omitted.
Read my original comment. It would very much depend on context, and, as I said, I'd be more inclined to do it in the false case. It's funny, you still seem to think there is a "right and wrong" here, and you can't see that coding style is just like writing a poem - each individual will do things a little differently.
What context does it depend on? Where is it reasonable to say (x == true) instead of x? Edit: your original post said "If I were writing something, and I really wanted to make it clear that I was testing a boolean to be true, I might write that." What does this even mean? Simply writing x isn't really really clear, so you write (x == true) to make it extra clear? if (x) is testing boolean to be true and it's crystal…
The clearest way I can think of to write that, that's hopefully less prone to misinterpretation is if(x == false) rather than if(!x)
Like I said, these are just my personal opinion and an expression of how I code (and likely things that I find difficult or often misread when reading the code of others)
A timely reminder to everyone: http://thedailywtf.com/ is still going strong! Be there or be ... competent?
I quit them when Alex tried to takeover Programming Praxis by force when negotiations didn't seem to be moving fast enough for him.
http://programmingpraxis.com/2009/08/13/the-daily-wtf-malici...
Earlier quoted context omitted.
>Another legacy app I'm employed to "repair" has one single 'template' for every page on the whole site. Its first ~500 lines conveniently consist of a giant and highly nested if/else clause to set the page variables and inline javascript. oh, oh! I'm doing one of those. Only, it's a modern, MVC version, so there's actually a couple of dozen controllers with a single function each, and all actions snake through The G…
Whenever something like that happens, this is my reference: http://developerexcuses.com
git commit -m "$(curl -s developerexcuses.com | sed -n '//{s/]*>//g;p}')"