61–70 of 82 posts
I'm pretty sure there hasn't been reason for anyone to do that for a decade or so, though.
public bool ShowOptional() { bool bolReturn = false; return bolReturn; } The above actually seems reasonable if you assume the programmer that wrote it was intelligent. I'm imagining that the above code is called multiple times by the application, for a new optional feature in development. Currently, they haven't developed the feature, and so we are always returning false. But in the future, we likely will want to sh…
return false;
Earlier quoted context omitted.
This reminds me of this one, which is quite common: return foo == null ? true : false;
I sometimes do that in PHP because I hate the equivalence between "", false, null, '0' and 0. Seeing true and false written out makes it more readable.
Earlier quoted context omitted.
From my experience, such code is not specific to MS technologies, but is indeed often found in “enterprisey” code, a lot of which just happens to be in Java and C#. And enterprisey code is like that because it's often outsourced to the lowest bidder. I once had to print a method that took 50 pages of paper, so I could understand what it does, and after 15 minutes I realized it's the same 60 lines repeated over and ov…
Just curious: Why does printing it on paper helps you to understand code better than reading it on screen?
A 4x6 table has far more surface area than even the biggest multi monitor set up
public bool ShowOptional() { bool bolReturn = false; return bolReturn; } The above actually seems reasonable if you assume the programmer that wrote it was intelligent. I'm imagining that the above code is called multiple times by the application, for a new optional feature in development. Currently, they haven't developed the feature, and so we are always returning false. But in the future, we likely will want to sh…
public bool ShowOptional()
{
return false;
}
?public bool ShowOptional() { bool bolReturn = false; return bolReturn; } The above actually seems reasonable if you assume the programmer that wrote it was intelligent. I'm imagining that the above code is called multiple times by the application, for a new optional feature in development. Currently, they haven't developed the feature, and so we are always returning false. But in the future, we likely will want to sh…
Why have a variable then? return false; Done.
A lot of these seem to be attempts to fit into existing "best practices". Unit tests that prove nothing. Boilerplate Java code that does nothing. Maybe we should reevaluate some best practices. I have debated before on here that many unit tests seem useless as the units are too small, and you essentially end up testing your language or framework which you already know works. Integration testing on the other hand make…
Oh my yes. As soon as you need more than one processor messing with an object they are invaluable. The only thing better is immutable objects.
It's also nice to have the object interface separate from object data if you want to change the object data representation without breaking everything (I don't know in general when you would do this, I just know I have done it before and getter/setters let me work faster to refactor).
Love this one: return foo == null ? null : foo;
That one makes a bit of sense in Javascript as it'd return null if foo was null OR undefined.
return !foo ? null : foo;I wonder how much of that is due to problems in documentation/documentation discoverability. This seems precisely the kind of data that we need to make docs better.