231–240 of 243 posts
Earlier quoted context omitted.
Six months? I come in after the weekend and constantly want to rewrite the whole goddamn thing.
This^ and I'm only a student; I'll write a program in the evening and by the following morning I'm all, no, no, no!
Earlier quoted context omitted.
eh, that's not so bad really. 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. Then I can be absolutely certain the person reading it in 5 years won't misread it. Actually, the more I think about it, the more I'd be inclined to do that in the false case ( ie if(aBoolean == false)... rather than if(!aBoolean).. ) because I worry that it's to…
Why stop there? To really get the point across, you may want to do: if (((((a == true) == true) == true) == true) == true) That way, you can be even more certain!
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…
I think you're misunderstanding the term. Legacy code -- like legacy lots of other things -- is the intersection of "bad" and "it's too late to fix now". Code which can be fixed easily isn't "legacy". Code where a replacement would need to be bug-for-bug compatible in order to avoid breaking things is "legacy".
Earlier quoted context omitted.
Came across this one yesterday, slightly paraphrased: boolean updateMsg(boolean pPassed) { if (pPassed) { incrMsgCounter(); logger.info("Message sent"); } else { logger.info("Failed to send"); return false; } return true; } Yes, the calling code actually checked the return value. The code is full of stuff like this. Somehow I've got a morbid fascination and can't stop marvelling at how grotesque it is. It even overpo…
What's so bad about this one? Other than its returning a boolean being pointless, I mean?
Earlier quoted context omitted.
The first time someone wanted to hire me was even before I started college. "so how much will you bill me?" "Well right now I get 7€ (9.2$ at current rate) for unloding trucks ..." He interupted me before I could finish the sentence and demand 8€. "I can not pay you 7€! taht is just to much!" Sooooo I declined but someone took the job ... for under 8$ an hour. How much quality can you expect for that price???
This sadly still happens. I remember looking through Craigslist jobs and legit companies wanting someone with html/css/javascript/php experience for $8/hr, kid you not.
Earlier quoted context omitted.
> So, you changed a somewhat reproducible bug into one that has about a four billion times lower chance of occurring? Yes. You seem to imply that's a bad thing? > Also, you introduced a new error condition: a corrupt packet that should set a value of 1, but arrives as a value of 2 will not initiate the landing routine. A corrupt packet should not do anything, so that's good, not an error. We do not want the landing r…
It was a bad thing, the way you described it. Now that I know you also fixed the root cause of the problem, I can see it as an additional line of defense. I think I wouldn't add it, though. Time is better spent on tooling that checks the variable doesn't get an incorrect value.
Earlier quoted context omitted.
Why stop there? To really get the point across, you may want to do: if (((((a == true) == true) == true) == true) == true) That way, you can be even more certain!
People have different preferences when it comes to coding styles. There are some that are subjective (balance between clarity vs. simplicity), and there are idiotic styles such as !Boolean.FALSE.equals(aBoolean), or if (((((a == true) == true) == true) == true) == true).
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…
I think you're misunderstanding the term. Legacy code -- like legacy lots of other things -- is the intersection of "bad" and "it's too late to fix now". Code which can be fixed easily isn't "legacy". Code where a replacement would need to be bug-for-bug compatible in order to avoid breaking things is "legacy".
You could be writing legacy code today.
Earlier quoted context omitted.
People have different preferences when it comes to coding styles. There are some that are subjective (balance between clarity vs. simplicity), and there are idiotic styles such as !Boolean.FALSE.equals(aBoolean), or if (((((a == true) == true) == true) == true) == true).
The point is that using (a == true) instead of a is idiotic. Now, there are good semantic reasons to use (a == true) in some languages, but we're not talking about that, we're talking purely about style. It's no different from doing (a && true) or (i + 0) or (f * 1.0) when a, i and f would suffice. Not only is it longer, it forces you to stop and think, was there a good reason why this was being done? Can a hold trut…
It's interesting you admit that people are doing it "the long way" because that's how it naturally flows out of their head.
Doesn't it make sense that it would naturally flow into their head the same way?
What's the goal here - write very tight, concise code that fits some arbitrary standard of "correct"?
Or to write code that flows out of and into people's heads easily?