visual C# 2005 exiting
-
Looking at your experience, i am sure you are definitely over 30 yrs of age. And mike is a kid in front of you...Common man..chill out now. It's not making you any better. Be nice with others and they ll be nice with you. ***Simple golden rule*** :)
-
Looking at your experience, i am sure you are definitely over 30 yrs of age. And mike is a kid in front of you...Common man..chill out now. It's not making you any better. Be nice with others and they ll be nice with you. ***Simple golden rule*** :)
Oh come on, it sure is fun and certainly made the day go by :laugh:
only two letters away from being an asset
-
Oh come on, it sure is fun and certainly made the day go by :laugh:
only two letters away from being an asset
-
haha he is trying to act like he doesnt care well he is probably about ready to run home to mommy to lick his wounds
-
Anyway mike you need to stop replying back now. Finish it now. He is quite elder to you..so you can take a initiative to be good with him by not stretching this more... All the best.
-
Looking at your experience, i am sure you are definitely over 30 yrs of age. And mike is a kid in front of you...Common man..chill out now. It's not making you any better. Be nice with others and they ll be nice with you. ***Simple golden rule*** :)
-
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 HemingwayEnnis 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
-
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 -
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 HemingwayEnnis 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
-
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 -
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 HemingwayEnnis Ray Lynch, Jr. wrote:
Sometimes I am a condescending A**, so you must forgive me
And I'm not :laugh: 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. :-D
led mike
-
Ennis Ray Lynch, Jr. wrote:
Sometimes I am a condescending A**, so you must forgive me
And I'm not :laugh: 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. :-D
led mike