|
> Why, of all things, should I work in a profession when I
> don't care about it or my skills at all?
Oh, you should definitely care about your skills and the profession, that's not what I'm saying at all.
What I'm saying is that it might not be easy to get the "right way" message accross.
You may find that it's better to seek out the people who are building software the right way, rather than try to change the culture you are faced with.
But good luck finding them.
-Rd
|
|
|
|
|
The instruction was very clear, exercise all aspects of the language features.
|
|
|
|
|
+3
Twas more like "as many features as you can muster" 
...byte till it megahertz...
|
|
|
|
|
i didn't even know goto statement still exist...
dev
|
|
|
|
|
One of the worst programming practice i have ever seen was like this,
Dim Comma As String = ","
and then he used this variable whenever he wanted to used Comma in other strings.
Initially i wondered what this Comma means and then clicked go to definition and just horrified.
murder of programming......
|
|
|
|
|
if someone start to create a role play game like this:
int enemyHP = 10;
int playerStrength = 3;
_TakeDamage:
switch (playerStrength)
{
case 1:
if (enemyHP == 1)
{
goto _EnemyDeath;
}
else
{
enemyHP = enemyHP - 1;
}
case 2:
if (enemyHP == 2)
{
goto _EnemyDeath;
}
else
{
enemyHP = enemyHP - 2;
}
case 3:
if (enemyHP == 3)
{
goto _EnemyDeath;
}
else
{
enemyHP = enemyHP - 3;
}
case 4:
if (enemyHP == 4)
{
goto _EnemyDeath;
}
else
{
enemyHP = enemyHP - 4;
}
case 5:
if (enemyHP == 5)
{
goto _EnemyDeath;
}
else
{
enemyHP = enemyHP - 5;
}
}
_EnemyDeath:
Console.WriteLine("Enemy is death!");
Then there is no hope for the game... xD
This is really untopable!
|
|
|
|
|
In some old code, I discovered following gem:
do
{
try
{
BDTLine line = new BDTLine(File);
line.Read();
Lines.Add(line);
}
catch (Exception ex)
{
System.Diagnostics.Trace.WriteLine("Exception reading BDT file: "+ex.Message);
break;
}
} while(true);
The file seems to be read line by line, but actually line.Read() reads a number of bytes. Some when the end of the file is reached, and it reads the next 7 bytes, an exception is thrown which is caught in the block above, which then stops further reading of the file; the error message nicely fills the log file. Great idea!
|
|
|
|
|
Is this in Java?
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word.
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
Nope, Java would have camelCase method names.
|
|
|
|
|
I'm not really a .NET programmer, so I might be missing something here. I would expect this to break out of the do-while loop after the exception has been logged. So, if it breaks out of the infinite loop after writing to the log, why would it fill the log file? And surely it will only write to the log file if Trace is enabled? So in a production environment I wouldn't expect it to write anything at all.
I'm not defending using infinite loops to process something that isn't endless like this, I think it's bad practice, but I don't understand why this would just keep writing error messages endlessly to the System Trace log, which is what the poster seems to suggest.
As I said, I'm not a C# programmer really, so maybe there's something going on here I'm not aware of.
|
|
|
|
|
you would be right if the while loop were inside the try block; as it is now, once something goes wrong the while loop keeps executing, causing ever more exceptions.
|
|
|
|
|
So, if this is C#, the break takes you where?
To find out, I tried this:
do
{
try
{
int a = 1;
int b = 0;
int c = a / b;
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
break;
}
} while (true);
When the DivideByZeroException gets caught, it breaks out of the do-while loop, and does not keep showing the MessageBox over and over. Why is this different from the original example? I must be missing something obvious here.
|
|
|
|
|
You're right, the break prevents an eternal loop. Nevertheless the following is the normal way:
try
{
do
{
int a = 1;
int b = 0;
int c = a / b;
} while (true);
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
}
as its structure better matches the intended operation, which is illustrated by the fact the break is not present anymore.
|
|
|
|
|
Either way, it's a pretty sucky way to do things. I'm guessing that this is forced on the programmer because the BDTLine class is badly designed so the only choice is to continue to read until it throws an exception.
|
|
|
|
|
But why us do with while(true)?
|
|
|
|
|
I wouldn't. When I need forever, I use
for(;;) {...}
and in C I would even
#define forever for(;;)
and yes I know I could do that in other C-like languages too using the/a pre-processor.
|
|
|
|
|
Loop should exit on first exception if there is no try block. I agree with you in this case it wouldn't stop excuting as it has a catch block. But I wonder if it will ever throw end of file exception? as everytime a new Object is created against physical file that would start reading file from start so there would be no end of file ever. but it could throw infinite loop exception though?
Your thoughts?
R A M
|
|
|
|
|
You missed the break in the catch block. And so did I initially. It is ugly; if the goal is to leave the loop on exceptions, then the loop should sit inside the try block, not the other way around.
|
|
|
|
|
I understand.. but my point is will that read anything after first line as Object to read file is initiated EVERYTIME in loop
R A M
|
|
|
|
|
I can't tell from what is shown.
Is file a string, and BDTline opening said file?
or is file some kind of object (say a StreamReader), that has the file opened earlier on, and parses/returns a single line?
|
|
|
|
|
It breaks out of the loop with the first exception encountered, which is typically a System.IO.EndOfStreamException because the last line from which is read is always empty. And the normal way to leave that loop is exactly this exception. Every file read will cause three such lines in the log file (later on, the file is read another two times - it is certain that it has not changed between reads...). The next file causing another three lines in the log, and so on. When searching for the cause of a different error I was severely mislead by these messages.
|
|
|
|
|
This looks bad pratice to me, to break loop on exception, rather then actually detecting and comparing EOF character.
Ravi S
Coding is my birth-right and bugs are part of feature my code has!
_________________________________________
Me
Facebook
Twitter
|
|
|
|
|
Simply bad design and very poor naming conventions.
1) Call things what they are, nothing more, nothing less.
Class BDTLine should be BDTFile
line should be lines
.Read method should be .ReadLine (or should it be ReadBytes?)
Now when you look at the code you can see why it is loaded with problems.
2) BDTFile is an implementation nightmare for you or anyone else in the future.
2a) If the caller manages the loop, the class must expose a property to determine when to stop.
<br />
public bool EOF { <br />
get { return sr.Peek > -1; }
}<br />
<br />
_eof=((input=sr.ReadLine())==null)<br />
get { return _eof; }
2b) if the class manages the loop, either pass the lines reference or return the desired result from the Read method.
3) Finally there is no excuse for using do...while(true), period.
Dwayne J. Baldwin
|
|
|
|
|
Maybe it's just me, but using code that could cause an exception would mean that I'd rewrite it to not cause an exception. Why wouldn't you just do something like:
try
{
StreamReader sr = new StreamReader("TestFile.txt");
string data = sr.ReadToEnd();
string[] lines = data.Split(Environment.NewLine.ToCharArray());
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
|
|
|
|
|
A couple of years back I had a chap working in my team who knew various .Net specifics but didn't really seem to understand programming at all. He produced various pieces of "interesting" code but this was his finest hour:
bool moreThanOneModelTypes = (vehicle.PossibleTypes.Length > 1);
switch (moreThanOneModelTypes)
{
case true:
this.ddlVehicleFullModelType.Items.Add(new ListItem("- - - please select - - -", "-1"));
goto default;
case false:
goto default;
default:
foreach (VehicleType vehicleType in vehicle.PossibleTypes)
{
this.ddlVehicleFullModelType.Items.Add(new ListItem(vehicleType.DisplayName, vehicleType.Id));
}
_fullVehicleModelTypeReload = false;
break;
}
So that's a single-line if statement replaced with a multi-line switch, plus some gotos for good measure all because he got bored of if..else.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
