|
xxmikexx wrote: i am just trying to learn and not fail... i have a deadline
What did you do with the rest of the semester then?
only two letters away from being an asset
|
|
|
|
|
i have been learning and our semester just started...
|
|
|
|
|
xxmikexx wrote: i have been learning
I guess you are not a quick learner. You must be the first one.
what happens if you get better at programming, you add more x's to your name?
led mike
|
|
|
|
|
guess not i am damn sure you didnt learn how to program for yourself in 3 days i have spent alot of time trying to find websites were i can learn that are not blocked this is a new thing i can not do and all i know is i am definetly not coming back here for help any more a few people on here are very helpfull but just a couple people are incredibly annoying, i dont see what i did wrong i tried looking it up for my self then i figured i would ask for help and the reason i have the X's in my name is because i hate numbers in my name also this is the same name i have had on all the websites i go to one user name thats it so....
modified on Wednesday, March 19, 2008 5:03 PM
|
|
|
|
|
Wow you really got him fired up. I almost suffocated trying to read his post to me without taking a breath.
led mike
|
|
|
|
|
... do you have a problem reading in your head?
|
|
|
|
|
Guess he is struggling in his writing courses also. Punctuation is overrated anyway.
only two letters away from being an asset
|
|
|
|
|
Mark Nischalke wrote: Punctuation is overrated anyway.
So is... oh never mind I don't have time to do the rest of that thought justice. It's beer thirty, CYA!
led mike
|
|
|
|
|
y are you such a douchebag?(Mark Nischalke) honestly why do people like you even exist
|
|
|
|
|
The equivalent to exit sub in C# is return, as in return to the books and learn the language before trying to write programs with it.
only two letters away from being an asset
|
|
|
|
|
i would by choice but for class i have to make programs as i go along...
but thanks for the help saved bundles of time
|
|
|
|
|
Return is not allowed inside of methods more than once and should not be used by any method that does not have a functional result. Doing so is a poor programming practice that violates the one-in, one-out principle. You should use a proper combination of if, elseif, and else blocks to properly ensure program flow execution.
(When I was a TA I took points off for liberal use of return)
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
ok thanks but the reason i need it is if the first block of if statements is executed it will also execute the rest i want each one to trigger at a different time, i am making a program were you click a spot on the screen and it sends waves out i have it working but it just does it really quick if i use this it will wok for sure thanks for the advice tho
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Return is not allowed
Not allowed, or not recommended? Two different things. I don't know of any language that places a restriction on the number of return statements that can be used in a block of code. However, yes, good design principles dictate that you should have as few exit points as possible.
The original question only asked what the equivalent of VB's exit sub was, not how it should be used. Both Mike and I answered that direct question. Saying "Don't listen to anyone else" is a bit over the top.
only two letters away from being an asset
|
|
|
|
|
Anyone with the experience and judgment to disregard my statement would do so. Telling a novice not to do it is perfectly inline. A lot of the advice I give is structured to introductory programmers as more experienced developers have the experience to know when it is hogwash. By biasing my response towards less experienced developers I increase the value of the statements. I will repeat my statement with the inferred subtext:
"Return is not allowed unless you have the experience and judgment to properly identify cases for its use and understand the consequences both positive and negative"
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Return is not allowed inside of methods more than once
This isn't true. The C# language specification allows methods to contain multiple return statements.
The question to ask is whether a method should contain multiple return statements. The Microsoft Code Complete book makes some good arguments for and against this practice. There are definitely cases when multiple return statements make for greater readability and reduced complexity.
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Return is not allowed inside of methods more than once and should not be used by any method that does not have a functional result. Doing so is a poor programming practice that violates the one-in, one-out principle.
Yeah, that's what I thought also until I read Implementation Patterns by Kent Beck:
Back in the old days of programming, a commandment was issued: each routine shall have a single entry and a single exit. This was to prevent the confusion possible when jumping into and out of many locations in the same routine. It made good sense when applied to FORTRAN or assembly language programs written with lots of global data where even understanding which statements were executed was hard work. In Java, with small methods and mostly local data, it is needlessly conservative. However, this bit of programming folklore, thoughtlessly obeyed, prevents the use of guard clauses.
Guard clauses are particularly useful when there are multiple conditions:
[Code example snipped of nested if statements with a single return]
Nested conditionals breed defects. The guard clause version of the same code notes the prerequisites to processing a request without complex control structures:
[Code example snipped of flat if statements each with a return ]
Keep in mind there is more context to his segment on the Guard Clause. If you are interested I highly recommend the book.
All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.
Arthur Schopenhauer - German philosopher (1788 - 1860)
|
|
|
|
|
Unfortunately, the nature of business software development causes me to recommend against this. Using structured exists simplifies debugging and serves as a preventative measure from a junior programmer going haywire with a 10 page method. While I can say a deeply nested conditional does breed defects the case is made to follow Fowler on this one and refactor into more simpler methods.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Unfortunately, the nature of business software development
That book is specifically directed at business software. Again, I highly recommend it. There is no way I am going believe my perspective is more reliable than someone like Kent Beck. Following the advice of experts in the industry like Beck is what I have always done, I am not about to change that now.
Ennis Ray Lynch, Jr. wrote: the case is made to follow Fowler on this one
This is from the first page of the book:
"Many people don't realize how readable code can be and how valuable that readability is. Kent has taught me so much, I'm glad this book gives everyone the chance to learn from him." - Martin Fowler, chief scientist, ThoughtWorks
There are six people endorsing the book on that first page, one of them besides Fowler is Erich Gamma.
Ennis Ray Lynch, Jr. wrote: and refactor into more simpler methods.
The small excerpt I posted does not provide his entire discussion on the subject of Guard Clauses nor the context for the entire book nor the books discussion of refactoring into smaller methods. Perhaps before concluding his reasoning is wrong, you might want to read the book so you can know what his reasoning is before you decide to dismiss it.
led mike
|
|
|
|
|
I have read both books and I agree with the authors on many precepts, however, the books suffer from the fundamental flaw of assuming expert level developers or developers with motivation to develop good code. Most business environments I go to love to say, "We don't have blame here" or "No one owns the code". Those two premises invalidate both books as they lead to engineering disasters. My advice is not necessarily aimed at the ideal art of development because the ideal environment is usually corrupted.
With respect to guard classes there is another refactor that suggests it would be more appropriate to use inheritance to make a decision like this. Furthermore, in a guard class is is presumed that the early returns have a very low weighted value and are exceptional and not normal flow actions. The very reason for the guard clause is to illustrate the importance. Unfortunately, what I usually end up correcting is massive series of if-then-else statements spanning many pages littered with returns. I guess to put my opinion in context: if I came across a method with a well thought out series of guard clauses I would leave it alone. Unfortunately, I have seen virtually no methods that fall into the narrow scope of guard clauses and I have been around the block a few times.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Most business environments I go to love to say, "We don't have blame here" or "No one owns the code".
Ok, I understand you believe there are special circumstances ( though widely implemented) that make you believe it might not be practical, but that's not what you said:
Ennis Ray Lynch, Jr. wrote: Return is not allowed inside of methods more than once and should not be used by any method that does not have a functional result. Doing so is a poor programming practice that violates the one-in, one-out principle.
It's not poor programming practice. What you described is actually poor programming practice, you just think it's more practical given your stated circumstances. Or have I misunderstood your point?
led mike
|
|
|
|
|
I think we are beginning to understand. However, the point of my blanket statement is the fact that when introducing novice, inexperienced, or lazy programmers to the concept you cannot provide options. The allowance for violating the rule, is in my opinion, an advanced concept that a developer will naturally get on their own. My blanket statement will be ignored by anyone with the experience to do so and should be headed by anyone without the experience.
Maybe my error was in the presentation by saying not to listen to anyone else. However, experienced developers encouraging an inexperienced developer down the wrong path risks much. Sometimes I am a condescending A**, so you must forgive me :p
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Sometimes I am a condescending A**, so you must forgive me
And I'm not Yeah I wasn't concerned with that, just the statement of it being bad practice is all. No doubt the way the original poster was about to use it actually would be bad practice.
led mike
|
|
|
|
|
haha ya i just needed it to check input and if it was not correct exit and it worked thank you all
|
|
|
|
|
xxmikexx wrote: private void button1_Click(object sender, EventArgs e)
{
code to be run here
if (x ==5)
{
run more code
exit this block
}
more code here
}
From the look of your code, you don't need what you're asking for. A properly written if block is all it takes. You just about never need to use the "exit early" statements if the logic is laid out properly. Rewritten, you code translates to this:
private void button1_Click(object sender, EventArgs e)
{
if (x ==5)
{
}
else
{
}
}
|
|
|
|