|
the point was to do 2 column reversable order sorting, i wrote this thing as an intern.. have fun guys and gals.
int t1 = 0;
int t2 = 0;
string temp = "";
string orig = "";
if (lblSortOrder.Text==e.SortExpression)
{
Trace.Write("asdf","in order switcher");
lblSortOrder.Text +=" DESC";
}
else if (lblSortOrder.Text.IndexOf(e.SortExpression)== -1)
{
Trace.Write("asdf","in column adder");
temp=e.SortExpression;
temp+=", "+lblSortOrder.Text;
lblSortOrder.Text=temp;
}
else if (lblSortOrder.Text.IndexOf(',')!=-1)
{
if (lblSortOrder.Text.IndexOf(e.SortExpression)!=-1)
{
orig=lblSortOrder.Text;
t1=orig.IndexOf(e.SortExpression);
t2=orig.IndexOf(",",t1)-t1;
if(t2>=0)
{
temp=orig.Substring(t1,t2);
}
else
{
temp=orig.Substring(t1);
}
if(temp.IndexOf("DESC")!=-1)
{
orig=orig.Remove(t1,temp.Length);
temp=temp.Remove(temp.IndexOf("DESC"),4);
temp=temp.Trim();
}
else
{
orig=orig.Remove(t1,temp.Length);
temp+=" DESC";
temp=temp.Trim();
}
orig=orig.Trim();
lblSortOrder.Text=temp+","+orig;
}
else
{
lblSortOrder.Text=e.SortExpression;
}
}
else
{
lblSortOrder.Text=e.SortExpression;
}
lblSortOrder.Text=lblSortOrder.Text.Replace(",," , ",");
lblSortOrder.Text=lblSortOrder.Text.Replace(", ," , ",");
t1=lblSortOrder.Text.IndexOf(",",lblSortOrder.Text.IndexOf(",")+1);
if(t1>10)
{
lblSortOrder.Text=lblSortOrder.Text.Remove(t1,(lblSortOrder.Text.Length-t1));
}
Please remember to rate helpful or unhelpful answers, it lets us and people reading the forums know if our answers are any good.
|
|
|
|
|
Several years ago I was asked to evaluate a C program. The question was: can we fix it, or do we need to rewrite it?
What the program did and for whom doesn't matter, other than it should have been a straightforward business application: user-interface screens and database reads and updates.
The client was concerned that the program - used daily by several people for real work - was "flaky" and would often lock up or BSOD after 15-20 minutes.
So I started looking at the code...and found several interesting things:
- the program was using invisible pop-up windows as temporary data buffers to implement wizard-like operations in the user-interface, and never deallocating them.
- every variable was global
- there were no data structures anywhere for anything
- there were no functions other than those required by the GUI
- several functions were over 75 pages long - that's about 4500 lines of code in a single function
- the level of code redundancy was incredible; it was common to see the same 5-10 lines of code repeated several dozen times within the same function
Naturally, my recommendation was that the system be rewritten, preferably in an object-oriented language [which we did, but that was a Success Story, not a Horror Story].
My curiosity could not be held back, I had to know who had written this program...
This program was written by a COBOL programmer. It was her first C program, and her first GUI program.
I asked what happened to her. They said she got a job with a larger firm in the same industry just down the street - teaching C programming!
|
|
|
|
|
You know, those who can't code, manage. Those who can't manage... you know where they end up at..
|
|
|
|
|
|
Steven A. Lowe wrote: the program was using invisible pop-up windows as temporary data buffers to implement wizard-like operations in the user-interface, and never deallocating them.
Ahead of its time: garbage collection without the collection!
Steven A. Lowe wrote: every variable was global
But think of all the stack space you have!
Steven A. Lowe wrote: there were no data structures anywhere for anything
Or you could think of it as a data structure everywhere for everything.
Steven A. Lowe wrote: there were no functions other than those required by the GUI
Again, think of the saved stack space!
Steven A. Lowe wrote: several functions were over 75 pages long - that's about 4500 lines of code in a single function
But I bet Intellisense was nice and responsive.
Steven A. Lowe wrote: the level of code redundancy was incredible; it was common to see the same 5-10 lines of code repeated several dozen times within the same function
Man, haven't you heard of code reuse??
Faith is a fine invention
For gentlemen who see;
But microscopes are prudent
In an emergency!
-Emily Dickinson
|
|
|
|
|
David Kentley wrote: Ahead of its time: garbage collection without the collection!
5!
|
|
|
|
|
David Kentley wrote: Steven A. Lowe wrote:
the level of code redundancy was incredible; it was common to see the same 5-10 lines of code repeated several dozen times within the same function
Man, haven't you heard of code ref use??
fixed that for you.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
Steven A. Lowe wrote: I asked what happened to her. They said she got a job with a larger firm in the same industry just down the street - teaching C programming!
It is a shame
My first C class was thought by a guy who is good at COBOL but knows very little C. I made it through the class thinking, I am C Master. It did not occur to me how little I Knew until I took Data Structures with the toughest instructor in my life. I broke down and admitted I didn't knew C. He said, if you are willing to put up the time and effort I will help you. After painful semester, I learned C and felt very grateful. Because of that lesson I am a better developer now.
Yusuf
|
|
|
|
|
how about a C++ class taught by an accountant (by profession) handing out code examples that were not syntax correct?
Sorry to say, yes this is a true story. Good thing I was already working w/ C++
|
|
|
|
|
More proof that just knowing the syntax of a language is not enough to write high quality code.
Bill W
|
|
|
|
|
Steven A. Lowe wrote: several functions were over 75 pages long - that's about 4500 lines of code in a single function
That is just flat out a horror itself.
Steven A. Lowe wrote: asked what happened to her. They said she got a job with a larger firm in the same industry just down the street - teaching C programming!
That's even scarier.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
USE [Database1]
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
-- Validate User can hit the sql box. Basically doesn't do anything, except ensure I can see the sql box
-- Returns 1 if successful,
-- 0 l if failed (one could ask, If I can't see the box, how is it going to return 0....I don't know).
-- 3/26/04 (via name omitted)
-- Assumes SQL Server 7.0 SP1 or better
ALTER procedure [dbo].[CheckConnection]
@result char(1) OUTPUT
AS
set @result = "1"
RETURN
|
|
|
|
|
Hokay. So you can't just test the state of the connection then...
|
|
|
|
|
No of course not... security and permissions you know.
|
|
|
|
|
Austin Harris wrote: If I can't see the box, how is it going to return 0....I don't know
|
|
|
|
|
|
|
We used to have a standard stored procedure that did that. I pointed out that a successful 'ping' didn't mean anything at all: the server could be down or the connection lost by the time that the next call was made. It's been phased out.
Someone did claim that there was a problem with some old version of ADO that wouldn't return the results of the first stored procedure call you made after connecting, and so you called a dummy procedure before what you actually wanted to do. I'm skeptical - I've never seen a bug report on that. It smells of cargo-cult programming, and of the worst kind: chinese-whispers cargo-cult programming, where the implementor has heard that there's a problem and has heard that this will fix it, but has not experienced the problem themselves.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Here is an example from our current development effort:
CYesNoDlgBar *yesNoBar = new CYesNoDlgBar(this, prompt);
yesNoBar->SetCadPtr(this);
ShowCadBarModal(yesNoBar);
ret = yesNoBar->GetResult() ? 1 : 0;
if (yesNoBar)
{
delete yesNoBar;
yesNoBar = NULL;
}
Unfortunately I can't track down which developer put in this piece of code as we changed source control and lost that history otherwise he would have got a piece of my mind, as would the one who was supposed to do the code review.
Cheers,
Brett
|
|
|
|
|
LOL
Good luck of that coder... u changed ur source control...
Anand Desai
Developer
Atharva Infotech
|
|
|
|
|
Somewhat off topic: Never understood the people who allocate objects on heap when it is easier and safer to do it on stack. I.e.:
CYesNoDlgBar yesNoBar(this, prompt);
yesNoBar.SetCadPtr(this);
ShowCadBarModal(&yesNoBar);
ret = yesNoBar.GetResult() ? 1 : 0;
|
|
|
|
|
Haven't done any C++ for years but I agree. There's a general guideline I came across somewhere: "always use an object or a reference unless you have to use a pointer."
I saw lots of unnecessary heap allocation over the years. Why make trouble for yourself when you don't need to? Perhaps it's a sign of misplaced C++ "machismo?"
Kevin
|
|
|
|
|
Kevin McFarlane wrote: Perhaps it's a sign of misplaced C++ "machismo?"
On the contrary, I think it comes from the SmallTalk/Java style of OOP; create anonymous object and pass pointers/references to them around. Nothing wrong with that approach if you have a GC to clean up after you, but in C++ it is much better to create objects on stack than to worry about calling delete .
|
|
|
|
|
Nemanja Trifunovic wrote: Never understood the people who allocate objects on heap when it is easier and safer to do it on stack.
because C allows you to shoot yourself in the foot, but C++ blows it off...
(guess who said it)
Yusuf
|
|
|
|
|
It's hardly the stack that'll contribute to your foot's annihilation in C++...
--
Kein Mitleid Für Die Mehrheit
|
|
|
|