|
Eddy Vluggen wrote: Because that repeats the evaluation
good point
I may or may not be responsible for my own actions
|
|
|
|
|
musefan wrote: good point
Meh, too much VB, didn't notice the single equation-character
I are Troll
|
|
|
|
|
That's a brilliantly simple way to do things.
In short, there are two ways to solve a problem:
Just do it
Just do it, but do it in a better way!
-
Bits and Bytes Rules!
10(jk)
|
|
|
|
|
|
|
But, people like to use if statements!
I am happy if they at least use an else instead of another if.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
I think that both pieces of code are acceptable. While the original is much more verbose, that will lend itself to being understood by someone else. It additionally allows for easier maintenance should UI changes be needed.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
"Logics is really hard to learn?"
Don't you mean "Logics are really hard to learn?"
LOL, I'm just kidding.
Anyways, personally, I actually prefer the first one just because it's easier. My job involves 40 hrs a week of trying to decipher other people's written code and fix bugs. I love it, but I'll gladly take the simple-written code over the stuff I have to think over for a minute or so.
|
|
|
|
|
Even i like to go with first method, which makes the code more readable.
|
|
|
|
|
tabIndexZero is a poor choice for the identifier here, it should convey functionality; and statement reordering and better horizontal alignment could be used to improve readability, so maybe:
bool summaryMode = tabIndex == 0;
panelGeneral.Visible = summaryMode;
btnProjSetNext.Enabled = summaryMode;
panelTolerances.Visible = !summaryMode;
btnProjSetPrev.Enabled = !summaryMode;
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
You beat me to it, I was about to say both examples are bad. I don't give a rats behind about how long the code it, but if it't doesn't tell me what it's doing then it's bad.
Also, the second example makes explicit the oppositeness of
PanelGeneral.Visible and PanelTolerances.visible
btnProjSetNext.Enabled and btnProjSetPrev.Enabled
That oppositeness might be coincidental rather than fundamental. If so the first code is actually better than the second.
-Richard
Hit any user to continue.
|
|
|
|
|
Richard A. Dalton wrote: You beat me to it
only just.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
VUnreal wrote: This is twice as shorter!
What the heck does that mean? Twice as shorter than what?
|
|
|
|
|
I just came across the main table in the SQL Server database that stores info for my company's website. It has 170,000 records... and no indexes.
I have just remedied that by putting a clustered index on the primary key. I'll have to keep a look out for code that queries that table by fields other than the primary key... may need to add more indexes.
|
|
|
|
|
Indices! Indices! Dagnabit!
|
|
|
|
|
Yet you didn't point out the double negative.
|
|
|
|
|
Ah, but as a native speaker of American I can tell when a double negative is actually reenforcing the negativity rather than negating the negativity.
|
|
|
|
|
I'm not very familiar with SQL Server but shouldn't the primary key always be indexed automatically? (at least this is true for Oracle databases)
|
|
|
|
|
Yes, I believe creating a primary key will create an index automatically. However, it was only a primary key by reputation, not because somebody made it a primary key.
|
|
|
|
|
AspDotNetDev wrote: However, it was only a primary key by reputation, not because somebody made it a
primary ke
Erm you have bigger problems than a lack of indices then, don't you :whistles
|
|
|
|
|
|
I think the only clear solution is to take a step back from databases and go back to paper based systems. Much easier than adding a primary key, and will help create more jobs for the industry... WIN/WIN
And, are you sure you didn't get fooled?
I may or may not be responsible for my own actions
|
|
|
|
|
Don't know about win/win but the thought of dumping 10,000 pieces of paper on a business analyst's desk does have some appeal.
"You get that on the big jobs."
|
|
|
|
|
Big ouch.
|
|
|
|
|
Whenever we need to evaluate a performance problem at a customer the first thing we do is look for a missing index. Usually, this is the result of a messed up database installation but sometimes the damn thing is just not there. This kind of problem, as shameful as it is, is actually quite common. I've seen this on tables with millions of rows - no performance problem there eh?
|
|
|
|