Develop Reference

Assignment in method call bad practice?

This is my first question to Stackoverflow, although I have been a consumer for many years. Please forgive me if I break rules. That is certainly not my intent. I have strenuously reviewed the rules and believe I am within the bounds of acceptability. However, I would ask that you kindly point out usage errors, if they are present, so that I may in future be more compliant.
I teach programming to high school students. This semester we are doing C#. Last week we were studying recursion. I assigned several classic problems that can be solved with recursion, one of them being exponentiation.
One of my students submitted the following code as a solution for exponentiation using recursion (he did give me permission to post it here). The assignment in the method call gave me the willies, but when I told him that it was bad practice, he protested, saying that "it works", that it "made sense" to him, and that he "does it all the time".
static void Recur(int n1, int n2, int n3)
{
if (n2 > 0)
{
Recur(n1, n2 - 1, n3 *= n1); // this is the line in question
}
else
{
Console.WriteLine("The number calculated recursively is: {0}", n3);
}
}
I have had a hard time coming up with something concrete to tell my student about why making an assignment in a method call is bad practice in general, other than 1) the possibility of unintended side effects, and 2) the difficulty of maintenance.
I have searched online with every phrase I can construct concerning this question, but have come up pretty empty-handed. I did see a reference to a book called "Clean Code" by Robert C. Martin that I don't own.
My relationship with my students is somewhat like that of a parent. They sometimes don't put a lot of stock in what I say unless I can corroborate it with an independent source. If I could point to a definitive statement about putting assignments in a method call my student would be more inclined to stop this annoying habit.
Does this usage bother anyone else? Am I expecting too much in wanting him to change the way he's been doing things? He's 15, but with a promising future ahead of him. He's one of those students who just "gets it". I don't want him to develop bad practices.
Thank you for your time and input.

There are quite a few things improvable in the posted code:
Be consistent
Why isn't the call Recur(n1, n2 =- 1, n3 *= n1)? Why is n3 treated differently? This can cause confusion when reviewing/mantaining code.
Dont do unnecessary or superfluous work
Is n3 ever used after Recur(n1, n2 - 1, n3 *= n1)? No? Then why waste time assigning a value that is never used?
It's considered good practice to not mutate method arguments (unless they are passed in by reference of course). Why? Because it makes debugging and understanding how the code works much harder; having the initial conditions mutate as the method executes makes it much harder to track possible bugs, optimizations, improvements, etc.
All that said, I avoid these kind of patterns because I have really bad memory:
var i = 0;
Foo(i += 1);
Bar(i);
What is passed into Foo? Was it 0 or was it 1? I never remember and I have to look it up everytime. Chances are that whoever reviews this code can have the same problem. These clever tricks don't make the code work any faster or better and it avoids a grand total of one code line... not worth it.

The bad code is this one: n3 *= n1
Your student doesn't see any problem because method parameters are not final. Just define them final and you will see this peace of code will cause a compile error.
Why should one use final? Because this makes sure the method parameters will not be used for any other purposes inside the method. This makes the code less error prone, more reliable. Using one variably for one purpose makes also the code easier to understand by others which is important in the industry.
And as already pointed by others, assigning a value to n3 makes not sense because further on variable n3 is not used in the code.
His statement that this "makes sense to him" shows that he does not about software development in the real life, in the industry - starting from small companies and to Google or Facebook. One of the requirements is that the code should be maintainable. This peace of code is not.
Regarding "with a promising future ahead of him": How do you know that? Did he win any programming competition? His argument that he "does it all the time" is pretty weak. Ask him why does he do it? Give him a small research about the code quality. May be this will help him to understand software development a little bit.

Do you like languages that let you put the "then" before the "if"?

I was reading through some C# code of mine today and found this line:
if (ProgenyList.ItemContainerGenerator.Status != System.Windows.Controls.Primitives.GeneratorStatus.ContainersGenerated) return;
Notice that you can tell without scrolling that it's an "if" statement that works with ItemContainerGenerator.Status, but you can't easily tell that if the "if" clause evaluates to "true" the method will return at that point.
Realistically I should have moved the "return" statement to a line by itself, but it got me thinking about languages that allow the "then" part of the statement first. If C# permitted it, the line could look like this:
return if (ProgenyList.ItemContainerGenerator.Status != System.Windows.Controls.Primitives.GeneratorStatus.ContainersGenerated);
This might be a bit "argumentative", but I'm wondering what people think about this kind of construct. It might serve to make lines like the one above more readable, but it also might be disastrous. Imagine this code:
return 3 if (x > y);
Logically we can only return if x > y, because there's no "else", but part of me looks at that and thinks, "are we still returning if x <= y? If so, what are we returning?"
What do you think of the "then before the if" construct? Does it exist in your language of choice? Do you use it often? Would C# benefit from it?

Let's reformat that a bit and see:
using System.Windows.Controls.Primitives;
...
if (ProgenyList.ItemContainerGenerator.Status != GeneratorStatus.ContainersGenerated)
{
return;
}
Now how hard is it to see the return statement? Admittedly in SO you still need to scroll over to see the whole of the condition, but in an IDE you wouldn't have to... partly due to not trying to put the condition and the result on the same line, and party due to the using directive.
The benefit of the existing C# syntax is that the textual order reflects the execution order - if you want to know what will happen, you read the code from top to bottom.
Personally I'm not a fan of "return if..." - I'd rather reformat code for readability than change the ordering.

I don't like the ambiguity this invites. Consider the following code:
doSomething(x)
if (x > y);
doSomethingElse(y);
What is it doing? Yes, the compiler could figure it out, but it would look pretty confusing for a programmer.

Yes.
It reads better. Ruby has this as part of its syntax - the term being 'statement modifiers'
irb(main):001:0> puts "Yay Ruby!" if 2 == 2
Yay Ruby!
=> nil
irb(main):002:0> puts "Yay Ruby!" if 2 == 3
=> nil
To close, I need to stress that you need to 'use this with discretion'. The ruby idiom is to use this for one-liners. It can be abused - however I guess this falls into the realm of responsible development - don't constrain the better developers by building in restrictions to protect the poor ones.

It's look ugly for me. The existing syntax much better.
if (x > y) return 3;

I think it's probably OK if the scope were limited to just return statements. As I said in my comment, imagine if this were allowed:
{
doSomething();
doSomethingElse();
// 50 lines...
lastThink();
} if (a < b);
But even just allowing it only on return statements is probably a slippery slope. People will ask, "return x if (a); is allowed, so why not something like doSomething() if (a);?" and then you're on your way down the slope :)
I know other languages do get away with it, but C#'s philosophy is more about making The One Right WayTM easy and having more than one way to do something is usually avoided (though with exceptions). Personally, I think it works pretty well, because I can look at someone else's code and know that it's pretty much in the same style that I'd write it in.

I don't see any problem with
return 3 if (x > y);
It probably bothers you because you are not accustomed to the syntax. It is also nice to be able to say
return 3 unless y <= x
This is a nice syntax option, but I don't think that c# needs it.

I think Larry Wall was very smart when he put this feature into Perl. The idea is that you want to put the most important part at the beginning where it's easy to see. If you have a short statement (i.e. not a compound statement), you can put it before the if/while/etc. If you have a long (i.e. compound) statement, it goes in braces after the condition.

Personally I like languages that let me choose.
That said, if you refactor as well as reformat, it probably doesn't matter what style you use, because they will be equally readable:
using System.Windows.Controls.Primitives;
...
var isContainersGenerated =
ProgenyList.ItemContainerGenerator.Status == GeneratorStatus.ContainersGenerated;
if (!isContainersGenerated) return;
//alternatively
return if (!isContainersGenerated);

There is a concern reading the code that you think a statement will execute only later to find out it might execute.
For example if you read "doSomething(x)", you're thinking "okay so this calls doSomething(x)" but then you read the "if" after it and have to realise that the previous call is conditional on the if statement.
When the "if" is first you know immediately that the following code might happen and can treat it as such.
We tend to read sequentially, so reading and going in your mind "the following might happen" is a lot easier than reading and then realising everything you just read needs to be reparsed and that you need to evaluate everything to see if it's within the scope of your new if statement.

Both Perl and Ruby have this and it works fine. Personally I'm fine with as much functionality you want to throw at me. The more choices I have to write my code the better the overall quality, right? "The right tool for the job" and all that.
Realistically though, it's kind of a moot point since it's pretty late for such a fundamental addition in C#'s lifecycle. We're at the point where any minor syntax change would take a lot of work to implement due to the size of the compiler code and its syntax parsing algorithm. For a new addition to be even considered it would have to bring quite a bit of functionality, and this is just a (not so) different way of saying the same thing.

Humans read beginning to end. In analyzing code flow, limits of the short term memory make it more difficult to read postfix conditions due to additional backtracking required. For short expressions, this may not be a problem, but for longer expressions it will incur significant overhead for users that are not seasoned in the language they are reading.

Agreed with confusing , I never heard about this construction before , so I think correct way using then before if must always contents the result of else, like
return (x > y) ? 3 : null;
else way there is no point of using Imperative constructions like
return 3 if (x > y);
return 4 if (x = y);
return 5 if (x < y);
imho It's kinda weird, because I have no idea where to use it...

It's like a lot of things really, it makes perfect sense when you use it in a limited context(a one liner), and makes absolutely no sense if you use it anywhere else.
The problem with that of course is that it'd be almost impossible to restrict the use to where it makes sense, and allowing its use where it doesn't make sense is just odd.
I know that there's a movement coming out of scripting languages to try and minimize the number of lines of code, but when you're talking about a compiled language, readability is really the key and as much as it might offend your sense of style, the 4 line model is clearer than the reversed if.

I think it's a useful construct and a programmer would use it to emphasize what is important in the code and to de-emphasize what is not important. It is about writing intention-revealing code.
I use something like this (in coffeescript):
index = bla.find 'a'
return if index is -1
The most important thing in this code is to get out (return) if nothing is found - notice the words I just used to explain the intention were in the same order as that in the code.
So this construct helps me to code in a way which reflects my intention slightly better.
It shouldn't be too surprising to realize that the order in which correct English or traditional programming-language grammar has typically required, isn't always the most effective or simplest way to create meaning.
Sometimes you need to let everything hang out and truly reassess what is really the best way to do something.

It's considered grammatically incorrect to put the answer before the question, why would it be any different in code?

.net code readability and maintainability [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
There Currently is a local debate as to which code is more readability
We have one programmer who comes from a c background and when that programmer codes it looks like
string foo = "bar";
if (foo[foo.Length - 1] == 'r')
{
}
We have another programmer that doesn't like this methodology and would rather use
if (foo.EndsWith("r"))
{
}
which way of doing these types of operations is better?

EndsWidth is more readable to someone who has never seen C or C++, C#, or any other programming language.

The second one is more declarative in style but I can't tell you objectively if it is more readable sine readability is very subjective. I personally find the second one more readable myself but that is just my opinion.
Here is an excerpt from my article:
Most C# developers are very familiar
with writing imperative code (even
though they may not know it by that
name). In this article, I will
introduce you to an alternative style
of programming called declarative
programming. Proper declarative code
is easier to read, understand, and
maintain.
As professionals, we should be
striving to write better code each
day. If you cannot look at code you
wrote three months ago with a critical
eye and notice things that could be
better, then you have not improved and
are not challenging yourself. I
challenge you to write code that is
easier to read and understand by using
declarative code.

Number 2 is better to read and to mantain.
Example: Verify the last 2 characters ...
Option 1)
if (foo[foo.Length - 1] == 'r' && foo[foo.Length - 2] == 'a')
{
}
Option 2)
if (foo.EndsWith("ar"))
{
}
last 3? last 4?...

I come from a C/C++ background and I vote for Endswith!

Readability rules, especially if it implies intent.
With the first example I must discover the intent - which is left for interpretation. If it appears to have a bug, how do I know that's not intentional?
The second example is telling me the intent. We want to find the end character. Armed with that knowledge I can proceed with evaluating the implementation.

I think the second way is better because it is more easy to read and because the first one duplicates logic of EndsWith method which is bad practice.

I think the right answer would be the one that is actually correct. EndsWith properly returns false for empty string input whereas the other test will throw an exception trying to index with -1.

Not only is EndWith more readable, but also more 'correct'.
As a rule, if there is a framework method provided to do the job ... use it.
What if foo == string.Empty?

IMO, the intent of the original author is clearer in the second example. In the first, the reader must evaluate what the author is trying to accomplish by pulling the last index. It is not difficult, but requires more effort on the part of the reader.

Both approaches are valid, but the endswith method is easier to read in my opinion. It also does away with the potential to make typing mistakes etc with the more complicated form..

EndsWith is probably safer. But the indexer is probably faster.
Endswith probably checks to see if the input string is empty. They will probably both throw null reference exceptions. And the indexer will fail is the length is 0.
As for readability, they both say the same thing to me, but I have been programming for a while. The .EndsWith(...) is probably faster to grasp without considering context.

It pretty much does the same thing. However, it gets more complicated with more than one character in the endswith argument. However, the first example is slightly faster as it uses no actual functions and thus requires no stack. You might want to define a macro which can be used to simply make everything uniform.

I think the main criteria should be which of these most clearly says what the developer wants to do. What does each sample actually say?
1)Access the character at position one less than the length, and check if it equals the character 'r'
2)Check if it ends with the string "r"
I think that makes it clear which is the more maintainable answer.

Unless and until it does not affect the program performance, no problem you can use either way. But adding code comments is very important for conveying what is being accomplished.

From an error handling standpoint, EndsWith.

I much prefer the second (EndsWith) version. It's clear enough for even my manager to understand!

The best practice is to write code that is easily readable. If you used the first one, developers that are debugging your code may say, "What is this dev trying to do?" You need to utilize methods that are easily explained. If a method is too complicated to figure out, retract several methods out of it.
I would definitely say the second one, legibility and simplicity are key!
Also, if the "if" statement has one line, DONT BOTHER USING BRACES, USE A SINGLE INDENTION

Remember that in classic C, the only difference between a "string" and an array of characters is that terminating null character '\0', so we had to more actively treat them accordingly and to make sure that we did not run off the end of the array. So the first block of code bases its thought process on the concept of an array of characters.
The second block of code bases the thought process on how you handle a string more abstractly and with less regard to its implementation under the covers.
So in a nutshell, if you are talking about processing characters as the main idea behind your project, go with the first piece. If you are talking about preparing a string for something greater and that does not necessarily need to focus on the mechanics of the ways that strings are built -- or you just want to keep it simple -- go with the second style.
Some of this might summarize others' contributions at this point, but more analogously put, are you playing "Bingo();" or are you "playing a game with a two-dimensional array of random integers, etc.?"
Hopefully this helps.
Jim

"Code is written to be read by humans and incidently run by computers" SICP
EndsWith FTW!!

Why is C# Case Sensitive? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What reasoning exists behind making C# case sensitive?
I'm considering switching from VB.NET to take advantage of some language features (CCR and yield), and understanding the reasoning behind this difference may make the transition easier.
[UPDATE]
Well I took the plunge three days ago. Learning C# hasn't been particularly hard, I could barely remember my C++ days in the late 90's though.
Is the Case Sensitivity annoying me? not as much as i'd thought... plus I am finding that it actually is advantageous. I'm actually really happy with the CCR as a asynchronous coordination programming model. If only I had more time on the current project i'd port the code base into C# to take full advantage. Wouldn't be fair to my client though.
Assessing my current project now and I'm seeing blocking threads EVERYWHERE! AHhhh!!!
[UPDATE]
Well i've been programming in C# for nearly a year now. I'm really enjoying the language, and I really REALLY hate crossing over to VB (especially when it is unavoidable!)
And the case sensitivity thing? not even an issue

C# is case sensistive because it takes after the C style languages which are all case sensitive. This is from memory here's an MSDN link which is not working for me right now I can't verify.
I would also like to point out that this is a very valid use case:
public class Child
{
private Person parent;
public Person Parent
{
get { return parent;}
}
}
Yes you can get around this using prefixes on your member variables but some people don't like to do that.

They were probably thinking "we don't want people using SoMeVaRiAbLe in one place and sOmEvArIaBlE in another.

Consider the variable names in the following pseudocode:
class Foo extends Object { ... }
...
foo = new Foo();
Having case sensitivity allows conventions which use case to separate class names and instances; such conventions are not at all uncommon in the development world.

I think the fact that case can convey information is a very good reason. For example, by convention, class names, public methods and properties start with an uppercase letter by convention. And conversely, fields and local variables start with a lowercase letter.
After using the language for years, I've come to really enjoy this, code is much easier to read when you can read information simply from the casing of the words.
And that's why people do this sometimes, and it can make sense:
Foo foo = new Foo();
I do that all the time, it's very useful. If you think about it in a more useful situation like this:
Image image = Image.LoadFrom(path);
It just makes sense sometimes to call the instance the same thing as the class name, and the only way to tell them apart is the casing. In C++ the case-sensitivity becomes even more useful, but that's another story. I can elaborate if you're interested.

I think that having case sensitive identifiers can make code more readable, through the use of naming conventions, well, and even without naming conventions, the consistency enforced by case sensitivity ensures you that the same entity is always written the same way.

C# inherits the case sensitivity from C and Java, which it tries to mimic to make it easier for developers to move to C#
There might have been some good reasons for making C case sensitive when it was created three decades ago, but there don't seem to be any records on why. Jeff Atwood wrote a good article advocating for that case sensitivity might no longer make sense.

Probably copied from C, C++, Java, etc. or may be kept the same on purpose so that its similar to what other langauges have.

It was just a matter of taste on the C# langauge designer team. I am willing to bet it was for comonality with other C family languages. It does however lead to some bad programming practices such as a private field and its associalted property differing only in the case of the first letter.
EDIT:
Why might this be cosidered bad.
class SomeClass
{
private int someField;
public int SomeField
{
get { return SomeField; }
// now we have recursion where its not wanted and its
// difficult for the eye to pick out and results in a
// StackOverflowException.
}
}
Prefixing private fields with an _ or an m might make it easier to spot. Its not a huge biggie and personally I sill do exactly what I have just said is bad (so sue me!).

Parsing is also a tiny bit easier for case-sensitive languages. As long as there's no good reason to choose the non-case-sensitive way, why bother?

You are looking at this in a very limited way - from your point of view. Language designers must take into account a whole other set of considerations: cultural reasons, compatibility with other languages, common coding practices etc
All modern languages use case-sensitivity: which ones don't?
As someone who used BASIC for a number of years I got very tired of developers using different cases for the same variable. This sort of thing is very tiresome to look at and encourages sloppy programming. If you can't be bothered to get the case right - what else can't you be bothered to do?

From
.NET Framework Developer's Guide
Capitalization Conventions, Case-Sensitivity:
The capitalization guidelines exist
solely to make identifiers easier to
read and recognize. Casing cannot be
used as a means of avoiding name
collisions between library elements.
Do not assume that all programming
languages are case-sensitive. They are
not. Names cannot differ by case
alone.

My best guess as to the why it is case sensitive would be because Unix is case sensitive. Dennis Ritchie, the father of C also co-wrote Unix, so it makes sense that the language he wrote would coincide with the environment available at that time. C# just inherited this from its ancestor. I think this was a good decision on Microsoft's part, being that windows paths are not case sensitive.

I assume you'd like to see code like:
SomeField=28;
someField++;
somefield++;
SOMEFIELD++;
compiled as if SomeField in any casing variation is the same variable.
Personally, I think it's a bad idea. It encourages laziness and/or carelessness. Why bother properly casing the thing when it doesn't matter anyway? Well, while we're at it, maybe the compiler should allow misspellings, like SoemField++?

Naming. Names are hard to come by and you don't want to have to create a new name when talking about something similar or have to use some notation to set them apart.
Such scenarios are properties for fields or arguments in the constructor that you are about to assign to fields.

Does This ASP.NET Consultant Know What He's Doing?

The IT department of a subsidiary of ours had a consulting company write them an ASP.NET application. Now it's having intermittent problems with mixing up who the current user is and has been known to show Joe some of Bob's data by mistake.
The consultants were brought back to troubleshoot and we were invited to listen in on their explanation. Two things stuck out.
First, the consultant lead provided this pseudo-code:
void MyFunction()
{
Session["UserID"] = SomeProprietarySessionManagementLookup();
Response.Redirect("SomeOtherPage.aspx");
}
He went on to say that the assignment of the session variable is asynchronous, which seemed untrue. Granted the call into the lookup function could do something asynchronously, but this seems unwise.
Given that alleged asynchronousness, his theory was that the session variable was not being assigned before the redirect's inevitable ThreadAbort exception was raised. This faulure then prevented SomeOtherPage from displaying the correct user's data.
Second, he gave an example of a coding best practice he recommends. Rather than writing:
int MyFunction(int x, int x)
{
try
{
return x / y;
}
catch(Exception ex)
{
// log it
throw;
}
}
the technique he recommended was:
int MyFunction(int x, int y, out bool isSuccessful)
{
isSuccessful = false;
if (y == 0)
return 0;
isSuccessful = true;
return x / y;
}
This will certainly work and could be better from a performance perspective in some situations.
However, from these and other discussion points it just seemed to us that this team was not well-versed technically.
Opinions?

Rule of thumb: If you need to ask if a consultant knows what he's doing, he probably doesn't ;)
And I tend to agree here. Obviously you haven't provided much, but they don't seem terribly competent.

I would agree. These guys seem quite incompetent.
(BTW, I'd check to see if in "SomeProprietarySessionManagementLookup," they're using static data. Saw this -- with behavior exactly as you describe on a project I inherited several months ago. It was a total head-slap moment when we finally saw it ... And wished we could get face to face with the guys who wrote it ... )

If the consultant has written an application that's supposed to be able to keep track of users and only show the correct data to the correct users and it doesn't do that, then clearly something's wrong. A good consultant would find the problem and fix it. A bad consultant would tell you that it was asynchronicity.

On the asynchronous part, the only way that could be true is if the assignment going on there is actually an indexer setter on Session that is hiding an asynchronous call with no callback indicating success/failure. This would seem to be a HORRIBLE design choice, and it looks like a core class in your framework, so I find it highly unlikely.
Usually asynchronous calls have a way to specify a callback so you can determine what the result is, or if the operation was successful. The documentation for Session should be pretty clear though on if it is actually hiding an asynchronous call, but yeah... doesn't look like the consultant knows what he is talking about...
The method call that is being assigned to the Session indexer cannot be asynch, because to get a value asynchronously, you HAVE to use a callback... no way around that, so if there is no explicit callback, it's definitely not asynch (well, internally there could be an asynchronous call, but the caller of the method would perceive it as synchronous, so it is irrelevant if the method internally for example invokes a web service asynchronously).
For the second point, I think this would be much better, and keep the same functionality essentially:
int MyFunction(int x, int y)
{
if (y == 0)
{
// log it
throw new DivideByZeroException("Divide by zero attempted!");
}
return x / y;
}

For the first point, that does indeed seem bizarre.
On the second one, it's reasonable to try to avoid division by 0 - it's entirely avoidable and that avoidance is simple. However, using an out parameter to indicate success is only reasonable in certain cases, such as int.TryParse and DateTime.TryParseExact - where the caller can't easily determine whether or not their arguments are reasonable. Even then, the return value is usually the success/failure and the out parameter is the result of the method.

Asp.net sessions, if you're using the built-in providers, won't accidentally give you someone else's session. SomeProprietarySessionManagementLookup() is the likely culprit and is returning bad values or just not working.
Session["UserID"] = SomeProprietarySessionManagementLookup();
First of all assigning the return value from an asynchronously SomeProprietarySessionManagementLookup() just wont work. The consultants code probably looks like:
public void SomeProprietarySessionManagementLookup()
{
// do some async lookup
Action<object> d = delegate(object val)
{
LookupSession(); // long running thing that looks up the user.
Session["UserID"] = 1234; // Setting session manually
};
d.BeginInvoke(null,null,null);
}
The consultant isn't totally full of BS, but they have written some buggy code. Response.Redirect() does throw a ThreadAbort, and if the proprietary method is asynchronous, asp.net doesn't know to wait for the asynchronous method to write back to the session before asp.net itself saves the session. This is probably why it sometimes works and sometimes doesn't.
Their code might work if the asp.net session is in-process, but a state server or db server wouldn't. It's timing dependent.
I tested the following. We use state server in development. This code works because the session is written to before the main thread finishes.
Action<object> d = delegate(object val)
{
System.Threading.Thread.Sleep(1000); // waits a little
Session["rubbish"] = DateTime.Now;
};
d.BeginInvoke(null, null, null);
System.Threading.Thread.Sleep(5000); // waits a lot
object stuff = Session["rubbish"];
if( stuff == null ) stuff = "not there";
divStuff.InnerHtml = Convert.ToString(stuff);
This next snippet of code doesn't work because the session was already saved back to state server by the time the asynchronous method gets around to setting a session value.
Action<object> d = delegate(object val)
{
System.Threading.Thread.Sleep(5000); // waits a lot
Session["rubbish"] = DateTime.Now;
};
d.BeginInvoke(null, null, null);
// wait removed - ends immediately.
object stuff = Session["rubbish"];
if( stuff == null ) stuff = "not there";
divStuff.InnerHtml = Convert.ToString(stuff);
The first step is for the consultant to make their code synchronous because their performance trick didn't work at all. If that fixes it, have the consultant properly implement using the Asynchronous Programming Design Pattern

I agree with him in part -- it's definitely better to check y for zero rather than catching the (expensive) exception. The out bool isSuccessful seems really dated to me, but whatever.
re: the asynchronous sessionid buffoonery -- may or may not be true, but it sounds like the consultant is blowing smoke for cover.

Cody's rule of thumb is dead right. If you have to ask, he probably doesn't.
It seems like point two its patently incorrect. .NET's standards explain that if a method fails it should throw an exception, which seems closer to the original; not the consulstant's suggestion. Assuming the exception is accurately & specifically describing the failure.

The consultants created the code in the first place right? And it doesn't work. I think you have quite a bit of dirt on them already.
The asynchronous answer sounds like BS, but there may be something in it. Presumably they have offered a suitable solution as well as pseudo-code describing the problem they themselves created. I would be more tempted to judge them on their solution rather than their expression of the problem. If their understanding is flawed their new solution won't work either. Then you'll know they are idiots. (In fact look round to see if you have a similar proof in any other areas of their code already)
The other one is a code style issue. There are a lot of different ways to cope with that. I personally don't like that style, but there will be circumstances under which it is suitable.

They're wrong on the async.
The assignment happens and then the page redirects. The function can start something asynchronously and return (and could even conceivably alter the Session in its own way), but whatever it does return has to be assigned in the code you gave before the redirect.
They're wrong on that defensive coding style in any low-level code and even in a higher-level function unless it's a specific business case that the 0 or NULL or empty string or whatever should be handled that way - in which case, it's always successful (that successful flag is a nasty code smell) and not an exception. Exceptions are for exceptions. You don't want to mask behaviors like this by coddling the callers of the functions. Catch things early and throw exceptions. I think Maguire covered this in Writing Solid Code or McConnell in Code Complete. Either way, it smells.

This guy does not know what he is doing. The obvious culprit is right here:
Session["UserID"] = SomeProprietarySessionManagementLookup();

I have to agree with John Rudy. My gut tells me the problem is in SomeProprietarySessionManagementLookup().
.. and your consultants do not sound to sure of themselves.

Storing in Session in not async. So that isn't true unless that function is async. But even so, since it isn't calling a BeginCall and have something to call on completion, the next line of code wouldn't execute until the Session line is complete.
For the second statement, while that could be used, it isn't exactly a best practice and you have a few things to note with it. You save the cost of throwing an exception, but wouldn't you want to know that you are trying to divide by zero instead of just moving past it?
I don't think that is a solid suggestion at all.

Quite strange. On the second item it may or may not be faster. It certainly isn't the same functionality though.

Typical "consultant" bollocks:
The problem is with whatever SomeProprietarySessionManagementLookup is doing
Exceptions are only expensive if they're thrown. Don't be afraid of try..catch, but throws should only occur in exceptional circumstances. If variable y shouldn't be zero then an ArgumentOutOfRangeException would be appropriate.

I'm guessing your consultant is suggesting use a status variable instead of exception for error handling is a better practice? I don't agree. How often does people forgot or too lazy to do error checking for return values? Also, pass/fail variable is not informative. There are more things can go wrong other than divide by zero like integer x/y is too big or x is NaN. When things go wrong, status variable cannot tell you what went wrong, but exception can. Exception is for exceptional case, and divide by zero or NaN are definitely exceptional cases.

The session thing is possible. It's a bug, beyond doubt, but it could be that the write arrives at whatever custom session state provider you're using after the next read. The session state provider API accommodates locking to prevent this sort of thing, but if the implementor has just ignored all that, your consultant could be telling the truth.
The second issue is also kinda valid. It's not quite idiomatic - it's a slightly reversed version of things like int.TryParse, which are there to avoid performance issues caused by throwing lots of exceptions. But unless you're calling that code an awful lot, it's unlikely it'll make a noticeable difference (compared to say, one less database query per page etc). It's certainly not something you should do by default.

If SomeProprietarySessionManagementLookup(); is doing an asynchronous assignment it would more likely look like this:
SomeProprietarySessionManagementLookup(Session["UserID"]);
The very fact that the code is assigning the result to Session["UserID"] would suggest that it is not supposed to be asynchronous and the result should be obtained before Response.Redirect is called. If SomeProprietarySessionManagementLookup is returning before its result is calculated they have a design flaw anyway.
The throw an exception or use an out parameter is a matter of opinion and circumstance and in actual practice won't amount to a hill of beans which ever way you do it. For the performance hit of exceptions to become an issue you would need to be calling the function a huge number of times which would probably be a problem in itself.

If the consultants deployed their ASP.NET application on your server(s), then they may have deployed it in uncompiled form, which means there would be a bunch of *.cs files floating around that you could look at.
If all you can find is compiled .NET assemblies (DLLs and EXEs) of theirs, then you should still be able to decompile them into somewhat readable source code. I'll bet if you look through the code you'll find them using static variables in their proprietary lookup code. You'd then have something very concrete to show your bosses.

This entire answer stream is full of typical programmer attitudes. It reminds me of Joel's 'Things you should never do' article (rewrite from scratch.) We don't really know anything about the system, other than there's a bug, and some guy posted some code online. There are so many unknowns that it is ridiculous to say "This guy does not know what he is doing."

Rather than pile on the Consultant, you could just as easily pile on the person who procured their services. No consultant is perfect, nor is a hiring manager ... but at the end of the day the real direction you should be taking is very clear: instead of trying to find fault you should expend energy into working collaboratively to find solutions. No matter how skilled someone is at their roles and responsibilities they will certainly have deficiencies. If you determine there is a pattern of incompentencies then you may choose to transition to another resource going forward, but assigning blame has never solved a single problem in history.

On the second point, I would not use exceptions here. Exceptions are reserved for exceptional cases.
However, division of anything by zero certainly does not equal zero (in math, at least), so this would be case specific.